Lahme Verbindung, Hohe Pings zu init7

boma · 2020-04-01T16:32:37+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

boma

Hallo zusammen

Habe seit gestern massiv langsame Verbindungen zu schweizer Seiten und diversen vpn-Gateways meiner Kunden. Pings sind meist über 80ms und fallen auch immer mal wieder aus.

Meine UPC Leitung ist in Ordnung der cnlab Test gibt volle Bandbreite an. Auch Downloads von Internationalen Seiten funktioniert ohne Probleme.

Möchte somit sagen, dass nicht meine Leitung spinnt sondern wohl eher etwas beim Peering/Routing geändert wurde.

Hat sonst noch wer solche Probleme?

Gruess

Matthias

Roll

Hoffen wir mal das es jetzt vorangeht und die Streithälse sich finden

https://www.msn.com/de-ch/finanzen/top-stories/swisscom-verliert-prozess-um-weiterleitungsgebühren/ar-BB13mWly?ocid=spartandhp#page=2

GrandDixence

Neuigkeiten zum Peering UPC Cablecom<->Init7 gibt es vom PCTipp:

https://www.pctipp.ch/news/telekommunikation/streit-init7-upc-internet-verbindung-besser-2530186.html?ganzseitig=1

GrandDixence

Eine gute Zusammenfassung des Thema liefert Watson:

https://www.watson.ch/digital/schweiz/910152011-upc-schaltet-init7-peering-ab-das-ist-ein-einseitiger-akt-der-aggression

boma

Hab die Policy nochmals gelesen. Der letzte Absatz in den Minimum Requirements sagt:

If a potential peering partner doesn’t fulfil these requirements Liberty Global may nonetheless consider peering on the basis of other commercial and technical arrangements if this is in its interest.

In DE:

Wenn ein potenzieller Peering-Partner diese Anforderungen nicht erfüllt, kann Liberty Global dennoch ein Peering auf der Grundlage anderer kommerzieller und technischer Vereinbarungen in Erwägung ziehen, wenn dies in seinem Interesse liegt.

Jetzt könnte ja noch eine der technical and operational requirements nicht erfüllt sein. Aber falls dies nicht der Fall ist dann trifft nur das zu: “in Erwägung ziehen, wenn dies in seinem Interesse liegt.” = Sie haben kein Interesse!

boma

Ja wenn man sich stur an die Vorgabe hält (oder wohl besser: sich hinter ihr versteckt), dann wird es nicht funktionieren. Aber eben, einen gut bürgerlichen Schweizer Kompromiss müsste man anstreben. Ich weiss ja nicht, welche Vorgaben init7 nicht einhält, aber im Moment sieht es halt schon einfach so aus, als müsste UPC vom hohen Ross herunter kommen und halt auch einen kleineren Provider zulassen. Klar, Liberty interessiert sich nicht für die paar Kunden, die betroffen sind, aber vielleicht interessiert sich Liberty auch nicht dafür, wenn UPC-CH ein legacy-Peering still und heimlich aufbohrt. 😀

humschti

Wir sind in der CH halt nicht so gross - die Richtlinien sind den den USA sicher relevanter als hier. Und sich hinter diesen zu verstecken ist chli billig.

Gopf, in diesen Zeiten sind wir doch auf gute Verbindungen angewiesen!!! Bringt das Peering wieder hoch und guckt dann, wie das in Zukunft aussehen soll.

pato

@boma
Wenn du die UPC Peering Principles liest, reicht das nicht: https://www.libertyglobal.com/operations/business-services/global-peering-principles/
Die finde ich eh ein wenig extrem (minimum redundante 100 Gbps Anschlüsse (können auch 10× 10 Gbps sein), in zwei von UPC/Liberty Global gewählten Datencentern), etc.

humschti

Das wäre tatsächlich SEHR WÜNSCHENSWERT!

boma

Wenigstens reagieren sie:

https://magazin.upc.ch/en/media-2/stellungnahme_init7_upc/

Schön wäre, wenn sich die beiden Parteien an einen Tisch setzten würden und eine Lösung finden würde, die auch in schweizer Verhältnissen umsetzbar wäre. Einfach die derzeitigen 1Gbit Verbindungen auf jewils 10Gbit Verbindungen aufbohren. Braucht im besten Fall 4 neue SFP+ Module und fertig!

humschti

Im PDF der Init7 steht eine UPC Mailadresse. Ich habe gestern diese mal angeschrieben - bin gespannt ob ich da eine Antwort erhalte.

Vielleicht wollt ihr dies auch machen?

boma

Das ist ja schon eine ziemliche Verschlechterung. Bei mir siehts ähnlich aus:

Ping statistics for 77.109.144.219:
Packets: Sent = 300, Received = 300, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 133ms, Maximum = 149ms, Average = 137ms

Beim Arbeiten mittels VPN und RDP hats jetzt wieder eine merkliche Gedenksekunde, bis alles reagiert. Nicht so schlimm wie letzthin, aber es fühlt sich schon träger an.

Mal bei Twitter weiterverfolgen, wie es weitergeht mit dem Peering! Schon sehr bedauerlich, dass mal wieder ein grosser Provider versucht, die kleineren Konkurrenten zu benachteiligen. Ich war seit 20 Jahren zufriedener Cablecom-UPC Kunde und habe die Firma immer empfohlen und verteidigt. Jetzt wünsche ich mir eine Alternative, die es im Moment aber nicht gibt. Aber sollte die auftauchen, bin ich dann halt leider auch weg.

GrandDixence

Und hier die neusten Messresultate. Man vergleiche diese Messresultate mit den Messresultate im Beitrag Nr. 6:

# ping -A -c 1000 speedtest.init7.net

64 bytes from panthera.init7.net (213.144.138.186): icmp_seq=1000 ttl=51 time=133 ms

--- panthera.init7.net ping statistics —
1000 packets transmitted, 1000 received, 0% packet loss, time 132781ms
rtt min/avg/max/mdev = 130.186/132.778/143.135/1.335 ms, pipe 2, ipg/ewma 132.914/132.873 ms

GrandDixence

Ja, die Init7-Stellungsnahme sollte von jedem UPC-Endkunde aufmerksam durchgelesen werden! => Besonders das Schlusswort ist lesenswert.

https://drive.google.com/file/d/1F3rD_YW9DkAgFKVDsBNZyhuQTS0DLcTg/view

Die “neue” Peering-Politik von UPC Cabelcom ist “dicke Post” für jeden UPC-Endkunde!

Zu Lasten der zahlenden Endkunde spart die UPC Cablecom bei der Qualität des Internetanschlusses.

Wegen der inakzeptablen Peering-Politik sollte man Internetanschlüsse von UPC Cabelcom und Swisscom möglichst meiden.

humschti

https://twitter.com/init7/status/1250046672933175301

Wernilein

Das Netz scheint immer wieder wegen Ueberlastung zusammen zu brechen! Heute Sonntag blockiert alles. Anscheinend sind die Gamer aufgestanden.

boma

Hallo GrandDixence

Vielen Dank für die ausführliche Antwort und deine dafür aufgewendete Zeit!

Wie oben geschrieben, hat sich die Situation gestern im Laufe des Nachmittags wieder gebessert. Rein vom Arbeiten her ist es heute wieder wie immer.

Ich habe kurz zwei Messungen gemacht:

1. von meinem Mac via WLAN>VPN>speedtest.init7.ch (also so wie man es nicht machen sollte):

--- init7.ch ping statistics —

300 packets transmitted, 300 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 32.641/40.151/166.212/11.340 ms

2. von meiner Windows-Kiste via RJ45 direkt zu speedtest.init7.ch:

Ping statistics for 77.109.144.219:
Packets: Sent = 300, Received = 300, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 47ms, Average = 31ms

Somit heute keine Packet loss mehr. Diese hatte ich gestern gegen 18 Uhr zum teil noch.

Sieht so aus, als wäre jetzt wieder der normale Satus erreicht. Ob das in den letzten zwei Tagen eine Störung oder Überlastung oder sonstwas war, kann ich natürlich nicht wirklich beurteilen. Aber spekuliert hatte ich natürlich trotzdem! 😀

GrandDixence

Nein, das Problem ist offenbar “hausgemacht”.

Gemäss meinen Messungen ist der Netzwerkübergang zwischen UPC Cablecom und Init7 nicht überlastet. Die Messungen wurden am Donnerstagabend 02.04.2020 kurz nach 20 Uhr an einem 100/10 MBit/s Internetanschluss der UPC Cablecom mit EuroDOCSIS 3.0-Kabelmodem Ubee EVM3236 (im Bridge-Modus) durchgeführt.

Bei all meinen, unten aufgeführten Messungen wurde 0 % Paketverlustrate und sehr geringer Jitter festgestellt, somit ist der Netzwerkübergang zwischen UPC Cablecom und Init7 nicht überlastet!

Für mehr Informationen zur Messmethode (Adaptiver Ping+IPerf3) siehe:
https://community.sunrise.ch/t5/Connect-Box/Giga-Connect-Box/m-p/154343#M3800

Weiter sollte die Einhaltung der “Gute Performance-Regeln” kontrolliert werden:

https://community.sunrise.ch/t5/Internet-mit-Modem/Diagnose-Tool-der-Connect-Box-sagt-quot-Ihr-Heim/m-p/100045#M4573

Downstream (IPerf3 v3.3.7 unter Linux)
---—————————————————————————–
#iperf3 -u -R -t 30 -O 2 -c speedtest.init7.net -b 50M -l 1472

warning: UDP block size 1472 exceeds TCP MSS 1448, may result in fragmentation / drops
Connecting to host speedtest.init7.net, port 5201
Reverse mode, remote host speedtest.init7.net is sending
[ 5] local 192.168.3.40 port 38650 connected to 213.144.138.186 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 6.09 MBytes 51.1 Mbits/sec 0.041 ms 69/4409 (1.6%) (omitted)
[ 5] 1.00-2.00 sec 5.96 MBytes 50.0 Mbits/sec 0.022 ms 0/4246 (0%) (omitted)
[ 5] 0.00-1.00 sec 5.97 MBytes 50.0 Mbits/sec 0.018 ms 0/4250 (0%)
[ 5] 1.00-2.00 sec 5.95 MBytes 50.0 Mbits/sec 0.021 ms 0/4242 (0%)
[ 5] 2.00-3.00 sec 5.96 MBytes 50.0 Mbits/sec 0.034 ms 0/4246 (0%)
[ 5] 3.00-4.00 sec 5.96 MBytes 50.0 Mbits/sec 0.035 ms 0/4249 (0%)
[ 5] 4.00-5.00 sec 5.95 MBytes 50.0 Mbits/sec 0.047 ms 0/4242 (0%)
[ 5] 5.00-6.00 sec 5.96 MBytes 50.0 Mbits/sec 0.036 ms 0/4247 (0%)
[ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 0.018 ms 0/4245 (0%)
[ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 0.023 ms 0/4247 (0%)
[ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 0.093 ms 0/4245 (0%)
[ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 0.046 ms 0/4246 (0%)
[ 5] 10.00-11.00 sec 5.96 MBytes 50.0 Mbits/sec 0.031 ms 0/4246 (0%)
[ 5] 11.00-12.00 sec 5.96 MBytes 50.0 Mbits/sec 0.010 ms 0/4245 (0%)
[ 5] 12.00-13.00 sec 5.96 MBytes 50.0 Mbits/sec 0.029 ms 0/4246 (0%)
[ 5] 13.00-14.00 sec 5.93 MBytes 49.6 Mbits/sec 0.487 ms 0/4226 (0%)
[ 5] 14.00-15.00 sec 5.99 MBytes 50.4 Mbits/sec 0.026 ms 0/4266 (0%)
[ 5] 15.00-16.00 sec 5.96 MBytes 50.0 Mbits/sec 0.014 ms 0/4246 (0%)
[ 5] 16.00-17.00 sec 5.96 MBytes 50.0 Mbits/sec 0.037 ms 0/4246 (0%)
[ 5] 17.00-18.00 sec 5.96 MBytes 50.0 Mbits/sec 0.015 ms 0/4246 (0%)
[ 5] 18.00-19.00 sec 5.96 MBytes 50.0 Mbits/sec 0.060 ms 0/4246 (0%)
[ 5] 19.00-20.00 sec 5.96 MBytes 50.0 Mbits/sec 0.013 ms 0/4246 (0%)
[ 5] 20.00-21.00 sec 5.96 MBytes 50.0 Mbits/sec 0.022 ms 0/4245 (0%)
[ 5] 21.00-22.00 sec 5.96 MBytes 50.0 Mbits/sec 0.009 ms 0/4246 (0%)
[ 5] 22.00-23.00 sec 5.96 MBytes 50.0 Mbits/sec 0.025 ms 0/4243 (0%)
[ 5] 23.00-24.00 sec 5.96 MBytes 50.0 Mbits/sec 0.035 ms 0/4246 (0%)
[ 5] 24.00-25.00 sec 5.96 MBytes 50.0 Mbits/sec 0.017 ms 0/4246 (0%)
[ 5] 25.00-26.00 sec 5.96 MBytes 50.0 Mbits/sec 0.016 ms 0/4246 (0%)
[ 5] 26.00-27.00 sec 5.96 MBytes 50.0 Mbits/sec 0.020 ms 0/4245 (0%)
[ 5] 27.00-28.00 sec 5.96 MBytes 50.0 Mbits/sec 0.018 ms 0/4246 (0%)
[ 5] 28.00-29.00 sec 5.96 MBytes 50.0 Mbits/sec 0.028 ms 0/4246 (0%)
[ 5] 29.00-30.00 sec 5.96 MBytes 50.0 Mbits/sec 0.017 ms 0/4246 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.07 sec 179 MBytes 50.0 Mbits/sec 0.000 ms 0/127492 (0%) sender
[ 5] 0.00-30.00 sec 179 MBytes 50.0 Mbits/sec 0.085 ms 0/127488 (0%) receiver

iperf Done.

Upstream (IPerf3 v3.3.7 unter Linux)
---—————————————————————————–
# iperf3 -u -t 30 -O 2 -c speedtest.init7.net -b 5M -l 1472

warning: UDP block size 1472 exceeds TCP MSS 1448, may result in fragmentation / drops
Connecting to host speedtest.init7.net, port 5201
[ 5] local 192.168.3.40 port 33641 connected to 213.144.138.186 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 611 KBytes 5.00 Mbits/sec 425 (omitted)
[ 5] 1.00-2.00 sec 610 KBytes 4.99 Mbits/sec 424 (omitted)
[ 5] 0.00-1.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 1.00-2.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 2.00-3.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 3.00-4.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 4.00-5.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 5.00-6.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 6.00-7.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 7.00-8.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 8.00-9.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 9.00-10.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 10.00-11.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 11.00-12.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 12.00-13.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 13.00-14.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 14.00-15.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 15.00-16.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 16.00-17.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 17.00-18.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 18.00-19.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 19.00-20.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 20.00-21.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 21.00-22.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 22.00-23.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 23.00-24.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 24.00-25.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 25.00-26.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 26.00-27.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 27.00-28.00 sec 611 KBytes 5.00 Mbits/sec 425
[ 5] 28.00-29.00 sec 610 KBytes 4.99 Mbits/sec 424
[ 5] 29.00-30.00 sec 611 KBytes 5.00 Mbits/sec 425
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-30.00 sec 17.9 MBytes 5.00 Mbits/sec 0.000 ms 0/12738 (0%) sender
[ 5] 0.00-30.07 sec 17.9 MBytes 5.00 Mbits/sec 1.323 ms 0/12738 (0%) receiver

iperf Done.

Ping-Messung
---—————————————————————————–
# sudo ping -A -c 10000 speedtest.init7.net

64 bytes from panthera.init7.net (213.144.138.186): icmp_seq=10000 ttl=51 time=28.2 ms

--- panthera.init7.net ping statistics —
10000 packets transmitted, 10000 received, 0% packet loss, time 263390ms
rtt min/avg/max/mdev = 22.074/26.169/59.341/1.436 ms, pipe 3, ipg/ewma 26.341/26.420 ms

boma

Habe noch etwas zum Thema gegoogelt:

https://isp-blog.ch/upc-cablecom-peering-ins-init7-netz-ausbaufaehig/

Ist zwar schon älter, aber scheint immer noch so zu sein. Vielleicht müsste UPC die Politik diesbezüglich etwas ändern. Wegen Corona sind viele zur Heimarbeit gezwungen. Dafür werden sehr oft VPN-Zugriffe genutzt, die wohl oft auch zu anderen kleineren Providernetzten führen. Da wäre es wohl angebracht, dass man auch für diesen Use-Case die Netze ausrichtet und nicht nur fette Leitungen zu Netflix und Azure und co hat.

Momentan scheinen die Pings wieder etwas besser. Sind so zwischen 30-60ms. Arbeiten geht wieder einigermassen. Bis dann mal zum nächsten mal, wenn wieder das Peering verstopft ist.

boma

hmm scheint wirklich ein Problem mit dem Peering zu init7 (bei dem mein Arbeitgeber den Internet-Access hat) zu sein.

Bildschirmfoto 2020-04-02 um 09.48.16.png

Nächste Seite »