ConnectBox - Maximal 15Mbit/s UDP Durchsatz

final · 2015-11-20T06:49:17+00:00

Sunrise Community - I clienti aiutano gli altri clienti per tutto ciò che riguarda la televisione, Internet, il telefono e il cellulare. Registratevi ora!

ANMU

Hallo Zusammen

Der vollständigkeitshalber zur Info:

Wir lassen nun das Ubee - Modem in Betrieb. Sobald das Problem behoben sein sollte, wird sollte sich der 2. Level Support wieder bei mir melden, damit ich es nochmals testen kann.

ANMU

Hallo Zusammen

Der Second Level Support hat sich heute Nachmittag gemeldet ( an dieser Stelle, Besten Dank dafür ).

Wir haben uns entschlossen, mein “altes Ubee Modem” wieder in Betrieb zu nehmen, damit wir testen können, ob es damit wieder normal funktioniert.

Was soll ich sagen :-), abgesehen, dass das altbewährte Ubee Modem die 500 Mbit nicht erreichen kann, funktionierten alle VPN und TCP Test’s einwandfrei im Bridge Modus.

Somit ist mein aktuelles Fazit, dass das Problem im Modem Modus der Connect Box liegt.

Wer also ein Problem hat, kann die Connect Box im Router Modus betreiben, und danach globale eine Portweiterleitung an die interne Firewall setzen. Damit IPSec funktioniert, braucht es einfach einen VPN Server mit NAT-T oder IKEv2 Untersetzung.

Dies ist zwar nicht die Lösung, aber ein Workaround den man temporär verwenden kann, sofern man nicht mehrere externe IP’s benötigt.

Ob es die Hardware oder Firmware ist kann ich nicht abschliessend sagen. Vermute aber die Firmware.

Wie es nun weitergeht, weiss ich noch nicht. Der Second Level Support will sich morgen bei mir nochmals telefonisch melden, damit wir die Test’s und das weitere Vorgehen besprechen können.

Besten Dank an alle die sich hier an einer «Lösung» beteiligen.

ANMU

Guten Morgen

Kann sich der Second Level Support der sich gestern um 12.34 Uhr bei mir gemeldet hat, mich heute auf dem Mobile nochmals anrufen?

ANMU

Der UPC Support sagt, dass bei mir kein DS-Lite aufgeschaltet ist. Nun stellt sich die Frage, ob es trotzdem via IPv6 getunnelt wird?

GrandDixence

Die ConnectBox müsste eigentlich auch eine IPv6-Firewall haben. Da IPv4-Pakete durch IPv6 getunnelt werden, könnte die IPv4-Firewall UND die IPv6-Firewall der ConnectBox Einfluss auf die IPv4-Performance haben.

ANMU

Hallo Zusammen

Wo finde ich dann das Forum Kunde -》UPC ?

Es kann ja nicht sein, dass UPC mitliest und hofft das ein User das Problem löst.

Habs nun auch via IKEv1, IKEv2, NAT-T, L2TP, PPTP getestet auch von einem Gigabit Internet Anschluss mit unterschiedlichen Routern, immer mit dem gleichem Effekt…

Via tsclient voller Durchsatz, so wie ich es gerne hätte… VPN scheint irgend wo einen Flaschenhals zu haben (UPC ?).

Werde noch ein paar Tests am Wochenende durchführen und hoffe dann ein Fazit zu haben… Mal schauen…

Adriana

@Garuda Das wären dann eben unsere User ;-)

Gruss

Adriana

Garuda

@Adriana schrieb:

Sagt Bescheid, falls wir weiterhelfen können.

Falls cablecom über einen Fachexperten verfügt, dann lasst diesen zu Wort kommen.

Adriana

Salut @GrandDixence

Deine Forderung ist legitim. Da es jedoch ein Forum von Usern für User ist, wollen wir zuerst die User zu Wort kommen lassen, bevor wir uns an der Lösungsfindung beteiligen. Ich habe dich gefragt, da wir die anderen an deinem Wissen teilhaben lassen wollen – eigentlich ein schönes Kompliment 🙂

Sagt Bescheid, falls wir weiterhelfen können.

Liebe Grüsse

Adriana

Garuda

Falls bei cablecom ein Fachexperte arbeitet, dann dürfte dieser hier bald darüber informieren was das Problem ist, und was dagegen unternommen werden kann, bzw. was cablecom unternimmt um es zu lösen, und bis wann es gelöst sein sollte. Falls nichts kommt, muss wohl davon ausgegangen werden, dass cablecom über keinen Fachexperten verfügt.

GrandDixence

@Adriana schrieb:

Hallo @GrandDixence

Danke für deinen Tipp an @ANMU. Was hältst du von seinen Werten? Bin gespannt auf dein Feedback :smileyvery-happy:

Wir erwarten von der offiziellen Stimme der UPC Cablecom eine Präsentation einer Lösung des UDP-Performanceproblem der ConnectBox. Ich bin kein Angestellter der UPC Cablecom und bin nicht verpflichtet dieses Problem zu lösen. Jedoch zahlen wir als UPC Cablecom-Kunden hohe monatliche Raten für unseren Internetanschluss und erwarten eine entsprechende Gegenleistung. Ich erwarte von UPC Cablecom, dass ein Fachexperte sich diesem Problem annimmt und hier möglichst schnell eine akzeptable Lösung präsentiert wird.

Adriana

Hallo @GrandDixence

Danke für deinen Tipp an @ANMU. Was hältst du von seinen Werten? Bin gespannt auf dein Feedback :smileyvery-happy:

Liebe Grüsse

Adriana

ANMU

Guten Morgen

Entschuldige die fehlenden Angaben. Es handelte sich hierbei um eine Messung via IPSec.

Habe nun gestern Abend das ganze weiter getestet und eingeschränkt.

Resultat:

1. Wird der Modem-Modus verwendet, so wird für den IPSEC Kanal UDP 500 verwendet. Die Daten werden als verschlüsselte ESP Pakete versandt. Hier habe ich dann bis jetzt den max. Durchsatz von 25 Mbit.

2. Wird der Router-Modus verwendet, so wird für den IPSEC Kanal UDP 4500 verwendet, da dann NAT-T zur Anwendung kommt. Die Daten werden hier offensichtlich als UDP gesendet.

Nun kommt die Quiz Frage: Was soll man daraus schliessen?

Ist nun das Problem der Port UDP 500 oder das die Daten als verschlüsselte ESP Paket (Protokoll 50) versendet wird ?

Wie seht Ihr das ?

GrandDixence

@ANMU schrieb:

Im Router-Modus:

Connecting to host 10.0.0.12, port 5201
[ 4] local 10.1.1.101 port 62845 connected to 10.0.0.12 port 5201

Die wichtigste Information fehlt: Wie lautete der genaue IPerf3-Befehl mit allen Befehlsparameter? Nur so kann nachvollzogen werden, was genau für eine IPerf3-Messung durchgeführt wurde (UDP?, TCP?, welcher IPerf3-Server?).

Da die IPerf3-Messung von einer privaten IPv4-Adresse (10.x) auf eine private IPv4-Adresse (10.x) durchgeführt wurde, gehe ich von einer nicht sehr aussagekräftigen lokalen IPerf3-Messung mit TCP aus. IPerf3-Messungen sollten mit UDP auf den IPerf3-Server debit.k-net.fr durchgeführt werden.

ANMU

Hallo Zusammen

Danke für Eure Beiträge.

UPC Support, teilt mir mit, dass mein 500/50 Anschluss ein reiner IPV4 sei. Soweit ich das testen kann, stimmt es auch, da ich keine IPv6 Adresse erhalte. Ob dies aber im Hintergrund trotzdem in ein IPV6 Tunnel gepackt wird, weiss ich nicht und muss mich auf die Aussage verlassen, dass dies hier nicht der Fall sei.
Habe den Anschluss nun nochmals explizit mit den MTU Werten 1432 (Server + Client) und tiefere getestet:

Im Router-Modus:

Connecting to host 10.0.0.12, port 5201
[ 4] local 10.1.1.101 port 62845 connected to 10.0.0.12 port 5201
[ ID] Interval           Transfer     Bandwidth
[ 4]   0.00-1.01   sec 1.38 MBytes 11.4 Mbits/sec
[ 4]   1.01-2.00   sec 3.50 MBytes 29.7 Mbits/sec
[ 4]   2.00-3.00   sec 5.38 MBytes 45.1 Mbits/sec
[ 4]   3.00-4.00   sec 5.50 MBytes 46.1 Mbits/sec
[ 4]   4.00-5.00   sec 5.00 MBytes 41.9 Mbits/sec
[ 4]   5.00-6.00   sec 5.25 MBytes 44.0 Mbits/sec
[ 4]   6.00-7.00   sec 5.12 MBytes 43.0 Mbits/sec
[ 4]   7.00-8.00   sec 5.12 MBytes 43.0 Mbits/sec
[ 4]   8.00-9.00   sec 5.50 MBytes 46.1 Mbits/sec
[ 4]   9.00-10.00 sec 5.38 MBytes 45.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[ 4]   0.00-10.00 sec 47.1 MBytes 39.5 Mbits/sec                  sender
[ 4]   0.00-10.00 sec 47.1 MBytes 39.5 Mbits/sec                  receiver

iperf Done.

Im Modem-Modus (ohne irgendwelche andere Komponenten oder Konfigurationen anzupassen):

Connecting to host 10.0.0.12, port 5201
[ 4] local 10.1.1.101 port 52730 connected to 10.0.0.12 port 5201
[ ID] Interval           Transfer     Bandwidth
[ 4]   0.00-1.00   sec 2.25 MBytes 18.9 Mbits/sec
[ 4]   1.00-2.00   sec 2.38 MBytes 19.9 Mbits/sec
[ 4]   2.00-3.00   sec 2.25 MBytes 18.9 Mbits/sec
[ 4]   3.00-4.00   sec 2.88 MBytes 24.1 Mbits/sec
[ 4]   4.00-5.00   sec 2.38 MBytes 19.9 Mbits/sec
[ 4]   5.00-6.00   sec 2.50 MBytes 21.0 Mbits/sec
[ 4]   6.00-7.00   sec 3.00 MBytes 25.2 Mbits/sec
[ 4]   7.00-8.00   sec 2.12 MBytes 17.8 Mbits/sec
[ 4]   8.00-9.00   sec 3.00 MBytes 25.2 Mbits/sec
[ 4]   9.00-10.00 sec 2.25 MBytes 18.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[ 4]   0.00-10.00 sec 25.0 MBytes 21.0 Mbits/sec                  sender
[ 4]   0.00-10.00 sec 25.0 MBytes 21.0 Mbits/sec                  receiver

Daraus folge ich aktuell, dass dieses Modem im Modem-Modus die Performance nicht bringen kann, oder es liegt noch ein MTU Problem vor, wobei mein VPN Tunnel immer einen MTU von < 1433 hat, egal welcher MTU Wert beim Modem gesetzt ist.

Was ich nicht ganz versehe ist, warum es im Router-Modus nicht vorkommt. Da kann ich den MTU auf 1500 lassen und der Tunnel wird mit MTU 1432 erstellt mit vollem Durchsatz. Der Router-Modus müsste eigentlich mehr Probleme verursachen, als der reine Modem-Modus. Im Modem-Modus ändert sich der Durchsatz nicht gross, egal welchen MTU Wert ich im Modem oder dem Tunnel zuweise.

Via TCP ist beiden Modi kein Problem feststellbar. Somit muss es ja am UDP Protokoll liegen. Der VPN Kanal wird als IPSEC/ESP/AES256/MD5 erstellt.

GrandDixence

@ANMU schrieb:

Soweit ich dies nun getestet habe, scheint es im Routermodus nicht vorhanden zu sein. Hier erhalte ich den vollen Durchsatz, sofern ich dem VPN Kanal den MTU 1432 setze. Im Modemmodus, hilft der MTU Wert nicht. Hier hab ich eine instabile IPSEC Verbindung mit max. 15 - 25 Mbit.

Erscheint mir logisch: Im Routermodus werden dank Dual Stack Light (DS-Light) die IPv4-Pakete der VPN-Verbindung vom Kabelmodem mit einer privaten IPv4-Adresse durch einen IPv4-Tunnel an bestimmte Netzwerkkompenten der UPC Cablecom geschickt. Dort verlassen die IPv4-Pakete den IPv4-Tunnel und wandern durch das IPv4-Internet (Carrier-grade NAT CGN). Damit die IPv4-Pakete in den IPv4-Tunnel im Netzwerk der UPC Cablecom passen, dürfen die IPv4-Pakete nicht grösser als 1432 Byte sein (MTU 1432), wenn das IPv6-Kabelmodem im Router-Modus betrieben wird.

Sind die IPv4-Pakete zu gross (> 1432 Byte) für den IPv4-Tunnel, so werden alle zu grossen IPv4-Pakete vom Kabelmodem aufgeteilt (fragmentiert) und als kleinere IPv4-Pakete (< 1433 Byte) auf die Reise durch den IPv4-Tunnel geschickt. Am Ende des IPv4-Tunnels, auf irgendeiner UPC Cablecom-Hardware, verlassen die IPv4-Pakete den IPv4-Tunnel und werden durch einen NAT-Router geschickt. Im NAT-Router müssen die aufgeteilten IPv4-Pakete wieder zum ursprünglichen IPv4-Paket zusammen gesetzt werden (reassembliert), bevor die IPv4-Pakete mit einer öffentlichen IPv4-Adresse ausgestattet werden und auf die lange Reise durch das Internet geschickt werden.

Dies braucht einiges an Rechenleistung im NAT-Router der Cablecom und führt unweigerlich, immer zu einer massiven, spürbaren Performance-Einbusse (hier: Maximale Datenübertragungsrate < 26 MBit/s).

Bei der Entwicklung von IPv6 hat man aus den Fehlern bei IPv4 gelernt: Das Aufteilen (Fragmentieren) von zu grossen IPv6-Paketen ist generell immer verboten.

TCP kennt dieses IPv4-Tunnel-Performance-Probleme nicht, da dank dem Einsatz der Maximum Segment Size (MSS) die TCP-Paketgrösse so gewählt wird, dass eine Aufteilung (Fragmentierung) der TCP-Pakete nicht notwendig ist. Zustandslose Protokolle wie UDP und ESP (IP-Protokollnummer 50) kennen keinen Mechanismus zur Feststellung der maximalen Paketgrösse.

Interessant wären IPerf3-Messungen mit UDP-Paketen auf IPv4-IPerf3-Servern und der ConnectBox im Router-Modus. Für die Messungen muss zwingend die Netzwerkkarte des Quellrechners (der Rechner, welcher die UDP-Pakete aussendet) händisch auf ein MTU < 1433 konfiguriert werden.

ANMU

Hallo Zusammen

Gibt es diesbezüglich News?

Habe genau den gleichen Effekt. Soweit ich dies nun getestet habe, scheint es im Routermodus nicht vorhanden zu sein. Hier erhalte ich den vollen Durchsatz, sofern ich dem VPN Kanal den MTU 1432 setze. Im Modemmodus, hilft der MTU Wert nicht. Hier hab ich eine instabile IPSEC Verbindung mit max. 15 - 25 Mbit.

msi

@GrandDixence

Danke für deine Infos !

“Wir” haben aber nun mal die Connect Box und würden gerne die “Schwächen” finden bzw. kennen.

Vielleicht wird ja dann mal die Software/Firmware verbessert. 🙂

Ich persönlich werde sicher nicht “zurück” zum Ubee Modem wechseln.

Auch wenn ich eine Zeit lang Beta-Tester spielen darf. 🙂

In diesem Sinne …

Grüsse

GrandDixence

msi schrieb:

Ein wenig über 15 Mbits .. bzw. ca. 25 Mbit .. aber höher wird es auch nicht.

TCP werte sind unverändert.

Also die Firewall Einstellungen auf der Connect Box haben definitiv einen Einfluss auf den UDP (NAT) traffic.

Man müsste es wirklich testen, wie @GrandDixence es getestet hat ..

“Gemessen mit einem Internet 100-Kabelmodemanschluss (100 MBit/s Down, 10 MBit/s Up). Laptop per Gigabit-Ethernet-Kabel direkt verbunden an Ubee EVM32xx-Kabelmodem im Bridge-Modus.”

Also direkt an der Connect Box im “richtigen” Bridge Modus mit offizieller IPv4.

… test .. test .. test 🙂

Gruss

msi

Die von UPC Cablecom eingesetzten Kabelmodeme sind billige “Made-in-China”-Produkte mit zahlreichen Softwarefehlern drin. Deshalb sollte man als Cablecom-Kunde möglichst wenig dieser im Kabelmodem verbauter Hardware und Software nutzen. Das erreicht man, wenn man altbewährte Kabelmodeme wie das Ubee EVM32xx als reines IPv4-Kabelmodem im Bridge-Modus nutzt und auf Kabelmodem-Funktionen wie WLAN, Firewall, NAT-Routermodus etc. bewusst verzichtet.

Das Ubee EVM32xx unterstützt EuroDOCSIS 3.0 nur im Bridge-Modus bis 400 MBit/s (8 Kanäle gebündelt) im Downstream und 108 MBit/s (4 Kanäle gebündelt) im Upstream.

Wer ein nigelnagel neues Kabelmodem wie die Connect Box einsetzt, muss sich nicht über mangelnde Performance wegen zahlreicher Kabelmodem-Hardware- und Softwarefehlern wundern…

Dasselbe gilt leider auch für Firewall/NAT-Routern im Heimbereich. Ich musste selber feststellen, dass meine Firewall wegen einem Softwarefehler nicht die im Datenblatt präsentierte TCP-Datenübertragungsrate erreichen konnte, erst die Intervention beim Firewall-Hersteller und eine neue Firmware mit der Korrektur des Softwarefehlers brachte eine höhere TCP-Datenübertragungsrate.

Im Werbeprospekt zu meiner Firewall wird vollmundig die “Hardware-NAT”-Unterstützung angepriesen, jedoch musste ich die Funktion “Hardware-NAT” wegen Hardware-/Softwarefehler(n) schon kurz nach dem Kauf ausschalten, da es zu massiven Netzwerkstörungen kam.

Meine Firewall (LANCOM 1781EF+ im NAT-Modus ohne Hardware-NAT) und das Kabelmodem Ubee EVM32xx (reines IPv4 im Bridge-Modus) unterstützen gemäss den heute durchgeführten IPerf3-Messungen mit dem IPerf3-Server debit.k-net.fr 100 MBit/s im Downstream und 10 MBit/s im Upstream sowohl mit TCP wie auch mit UDP einwandfrei. Wegen der fehlenden einwandfreien Hardware-NAT-Unterstützung versuche ich gar keine schnellere Internetangebote aus (z.B. 250 MBit/s). Ohne einwandfreier Hardware-NAT-Unterstützung in der Heimnetzwerk-Firewall ist aus meiner Sicht die Nutzung eines Internetangebot > 150 MBit/s nicht sinnvoll.

Die Nutzung des IPerf-Server ping.online.net kann ich nicht empfehlen. Der IPerf-Server ping.online.net scheint ein Netzwerkproblem zu haben.

msi

Mein iperf3 client (192.168.x.x) sitzt hinter einem doppelten NAT.

Connect Box (router-modus / 1.NAT) —> Asus Router ( 2. NAT ) —> iperf3 client PC (win 7 sp1)

Das sind meine “alten” Werte von gestern ..

E:\perf-3.0.11-win64\perf3.exe -c ping.online.net -u -R -b 50M
Connecting to host ping.online.net, port 5201
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.x.x port 51612 connected to 62.210.18.40 port 5201
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.01 sec 648 KBytes 5.24 Mbits/sec 12.290 ms 716/797 (90%)
[ 4] 1.01-2.02 sec 248 KBytes 2.03 Mbits/sec 4.911 ms 782/813 (96%)
[ 4] 2.02-3.01 sec 240 KBytes 1.97 Mbits/sec 8.714 ms 734/764 (96%)
[ 4] 3.01-4.01 sec 216 KBytes 1.77 Mbits/sec 9.145 ms 731/758 (96%)
[ 4] 4.01-5.01 sec 232 KBytes 1.90 Mbits/sec 11.894 ms 734/763 (96%)
[ 4] 5.01-6.01 sec 248 KBytes 2.03 Mbits/sec 10.856 ms 732/763 (96%)
[ 4] 6.01-7.01 sec 224 KBytes 1.84 Mbits/sec 20.919 ms 687/715 (96%)
[ 4] 7.01-8.01 sec 240 KBytes 1.97 Mbits/sec 14.577 ms 746/776 (96%)
[ 4] 8.01-9.01 sec 240 KBytes 1.97 Mbits/sec 17.146 ms 721/751 (96%)
[ 4] 9.01-10.00 sec 240 KBytes 1.97 Mbits/sec 15.935 ms 733/763 (96%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 60.8 MBytes 51.0 Mbits/sec 16.205 ms 7390/7739 (95%)
[ 4] Sent 7739 datagrams

iperf Done.

Egal wann und was ich gemessen habe, die Werte blieben unverändert.

Nun habe ich die IP Flood detection .. etc. in der Connect Box IPV4 firewall ausgeschaltet .. Nur die Firewall selbst ist an.

screenshot.1448114063.jpg

Hier sind die Werte danach ..

E:\perf-3.0.11-win64>iperf3.exe -c ping.online.net -u -R -b 50M
Connecting to host ping.online.net, port 5201
Reverse mode, remote host ping.online.net is sending
[ 4] local 192.168.x.x port 61837 connected to 62.210.18.40 port 5201
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 3.10 MBytes 25.9 Mbits/sec 4.027 ms 449/846 (53%)
[ 4] 1.00-2.01 sec 2.92 MBytes 24.5 Mbits/sec 1.227 ms 344/718 (48%)
[ 4] 2.01-3.01 sec 3.12 MBytes 26.3 Mbits/sec 4.091 ms 405/805 (50%)
[ 4] 3.01-4.00 sec 2.98 MBytes 25.0 Mbits/sec 1.133 ms 340/721 (47%)
[ 4] 4.00-5.00 sec 3.09 MBytes 26.0 Mbits/sec 3.009 ms 409/805 (51%)
[ 4] 5.00-6.00 sec 2.88 MBytes 24.2 Mbits/sec 1.822 ms 353/721 (49%)
[ 4] 6.00-7.02 sec 3.05 MBytes 25.2 Mbits/sec 0.900 ms 437/827 (53%)
[ 4] 7.02-8.00 sec 2.56 MBytes 21.8 Mbits/sec 1.681 ms 376/704 (53%)
[ 4] 8.00-9.01 sec 2.96 MBytes 24.5 Mbits/sec 1.936 ms 430/809 (53%)
[ 4] 9.01-10.01 sec 3.05 MBytes 25.7 Mbits/sec 0.770 ms 375/766 (49%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.01 sec 60.8 MBytes 50.9 Mbits/sec 2.644 ms 3918/7743 (51%)
[ 4] Sent 7743 datagrams

iperf Done.

Ein wenig über 15 Mbits .. bzw. ca. 25 Mbit .. aber höher wird es auch nicht.

TCP werte sind unverändert.

Also die Firewall Einstellungen auf der Connect Box haben definitiv einen Einfluss auf den UDP (NAT) traffic.

Man müsste es wirklich testen, wie @GrandDixence es getestet hat ..

“Gemessen mit einem Internet 100-Kabelmodemanschluss (100 MBit/s Down, 10 MBit/s Up). Laptop per Gigabit-Ethernet-Kabel direkt verbunden an Ubee EVM32xx-Kabelmodem im Bridge-Modus.”

Also direkt an der Connect Box im “richtigen” Bridge Modus mit offizieller IPv4.

… test .. test .. test 🙂

Gruss

msi

« Pagina precedente Pagina successiva »