Verbindungsproblem zwischen zwei Standorten seit Frequenzumstellung bei Kabel Deutschland

[scarabeusCB]

Hallo Community.

Seit der Umstellung der Frequenzen im Kabelnetz am 21.08.2018 ist ein Verbindungsaufbau von mir (Remote Netzwerk genannt) zu einem bestimmten externen Server unbenutzbar stark eingeschränkt.

1. Wird eine Verbindung von einem Client aus dem Remote-Netzwerk (ISP: Kabel Deutschland) zu einem Server im Main-Netzwerk (ISP: 1&1-Netzwerk - letztendlich Deutsche Telekom) aufgebaut, ist ein Download nur mit einer extrem eingeschränkten Bandbreite (< 2-3 MBit/s) möglich.
2. Wird diese Verbindung über einen externen VPN geroutet ist die Bandbreite wie erwartet nur durch den Upload auf der Serverseite begrenzt (40 MBit/s). Also widersinnigerweise deutlich höher, obwohl der gesamte Traffic durch einen weiteren Server geleitet wird.
3. Wird eine Client Verbindung aus einem beliebigen anderen Netzwerk (anderer ISP) zu dem Server im Main-Netzwerk aufgebaut, ist die Bandbreite wie erwartet nur durch den Upload auf der Serverseite begrenzt (40 MBit/s). Ähnlich wie bei (2).

Vor der Umstellung der Frequenzen war die Verbindung wie unter (1) mit der erwarteten Bandbreite von 40 Mbit/s möglich.

Nach der Umstellung lagen massive Verbindungsprobleme zu allen externen Serververbindung vor, die ab ca. 10:00 Uhr morgens begannen und bis ca. 01:00 Uhr nachts (also über die gesamte Tageszeit) andauerten. Die Down/Uploadmessungen wurden über einen automatisierten DSL-Speedtest durchgeführt, der exklusiv die gesamte Bandbreite zur Verfügung am Standort hatte.
Siehe stündliche Bandbreitenmessung Download.2018.10.18-5days.jpg.

Der Upload war fast immer im guten Bereich. Upload.2018.10.18-5days.jpg

Kabel Deutschland hat ca. zwei Monate benötigt um auf dieses Problem zu reagieren und zu „lösen“:
Siehe Download.2018.11.25-5days.jpg und Upload.2018.11.25-5days.jpg

Die Verbindung zu dem o.g. Server ist trotzdem nur eingeschränkt möglich. Erst ein Routing über ein externes VPN stellt den alten Verbindungsstand wieder her.

Der Verbindungsstatus des Kabel Deutschland Modems wird als "gut" angesehen.

Generell:

• Wird aus dem Remotenetz eine direkte Verbindung zu dem Main-Netz aufgebaut, ist die Bandbreite stabil aber massiv eingeschränkt.
• Wird aus dem Remotenetz eine indirekte Verbindung über ein beliebiges externes VPN zum dem Main-Netz aufgebaut, ist die Bandbreite voll verfügbar.
• Eine Verbindung in die „andere Richtung“ ist immer mit der maximalen Bandbreite von ca. 10-12 Mbit/s möglich. So wie es vor, direkt nach der o.g. Frequenzumstellung und auch jetzt nach dem „fixen“ der Downloadbandbreite.

Topologie der Netze – siehe Network.Main.Remote.

(REMOTE)
Netzwerk mit den “Clients”
Angebunden über Kabel Deutschland, mit 200 MBit/s Down, 12 MBit/s Up
Fritzbox 7490 verbunden über Hitron CVE-30360 im BridgeMode
DynDNS über das MyFritz! Konto, wegen dynamischer IP

(MAIN)
Netzwerk mit den “Servern”
Angebunden über 1&1 - Telekomleitung, mit 100 MBit/s Down, 40 MBit/s Up
Fritzbox 7590 direkt verbunden mit DSL Leitung
DynDNS über das MyFritz! Konto, wegen dynamischer IP
Portfreigaben auf den jeweiligen Testserver


Varianten der Verbindung von (1):

• unabhängig vom Client im Remote Netzwerk:
  Laptop, Apple TV, Synology,...
• unabhängig vom Routing des Remote Client zum Main Server
  * Verbindung per MyFritz! Hostname und Portfreigabe im Main-Netz
  * Verbindung per externer IP-Adresse und Portfreigabe im Main-Netz
  * Verbindung per VPN-VPN-Kopplung über die Fritzboxen über die entfernte lokale IP-Adresse des Servers im Main-Netz (Aufgrund der Leistungsbeschränkung der Fritz-Boxen sind hier nur ca. 10-12 Mbit/s möglich, die aber nicht annähernd erreicht werden).
  * Verbindung per VPN- Kopplung über den VPN Server der Synology Main über die virtuelle IP-Adresse des Servers
• unabhängig vom Routing des Remote Client im Remote Netz:
  * über die Fritzbox und das Kabel Modem
  * direkt mit Kabel Deutschland Router im BridgeMode als einziger Client:
  „Laptop Remote“ oder „Laptop Remote direct“
• unabhängig vom Server im Main Netzwerk
  Synology, Laptop, Raspberry,...

Es wirkt, als ob die direkte Verbindung von Kabel Deutschland zu diesem Netz im Telekomnetz gedrosselt wird:

• Wird direkt oder über interne VPNs eine Verbindung vom Kabel Deutschland Netz aufgebaut – der ISP Kabel Deutschland kann also über die IP den Server im Telekomnetz identifizieren - ist die Verbindung gedrosselt.
• Wird eine Verbindung vom Kabel Deutschland Netz zu einem externen VPN Server aufgebaut – der ISP Kabel Deutschland identifiziert über die IP einen anderen Server - ist die Verbindung ohne Einschränkung möglich. Dieses externe VPN kann in einem beliebigen Firmennetzwerk realisiert werden (mehrere Varianten probiert) oder über andere VPN-Anbieter in verschiedenen Städten oder Ländern aufgebaut sein.

Fällt den Experten hier im Forum zu diesem Problem etwas ein?

 

[hantelfix]

wie sind die modem werte von kabel modem
https://www.kdgforum.de/download/file.php?id=645

 

[martinallnet]

Kann auch einfach an schlechten Peering zwischen den Netzen liegen.
Durchs VPN nimmt der Traffic evtl. eine andere Route und ist dann dort schneller.

 

[brainDotExe]

Das einem Provider immer direkt Drosselung unterstellt wird...
Hier wird vermutlich irgendwo ein Peering dicht sein.

 

[scarabeusCB]

wie sind die modem werte von kabel modem
https://www.kdgforum.de/download/file.php?id=645

Die "sollen" gut sein, und wenn ich das (laienhaft) vergleiche, scheint das auch zu stimmen.

 

[scarabeusCB]

Das einem Provider immer direkt Drosselung unterstellt wird...
Hier wird vermutlich irgendwo ein Peering dicht sein.

Ich wollte da nichts unterstellen...
Neutraler: auf dem Weg von den Endpunkten ist die Verbindung irgendwo gedrosselt.

Danke für die Hinweise zum Peering-Problem, das klingt plausibel.
Bleibt ein solches Problem, wenn man nichts unternimmt? Das ist jetzt seit diversen Wochen so und scheint stabil schlecht zu bleiben.
Oder konkreter: An wen müsste ich mich in diesem Fall wenden, damit das Problem gelöst wird?

 

[h00bi]

Bleibt ein solches Problem, wenn man nichts unternimmt? Das ist jetzt seit diversen Wochen so und scheint stabil schlecht zu bleiben.

Ich betreue deutschlandweit 10+ Anschlüsse in insgesamt 6 verschiedenen Netzen.
Diese verbinden sich auf das Hauptnetzwerk, welches über 2 verschiedene Netze erreichbar ist.

Grundsätzlich kommt es immer wieder (jedes Quartal) mal vor dass die Verbindung von Origin-A zu Destination-B schlecht ist. Hier hilft bei uns oftmals ein Wechsel auf das zweite WAN des Hauptnetzwerks.

Insbesondere treten diese Probleme auf:
Von Unitymedia Anschlüssen auf Telekom
Von EWE auf Unitymedia

Grundsätzlich melde beim Origin Anschlussprovider eine Störung und beschreibe präzise welche Route gestört/dicht ist. Nach ein paar Werktagen sind diese Probleme dann oftmals auch behoben.

Du hast hier aber auch (vermutlich) Consumer Anschlüsse an Consumer Hardware. Wie sich die ISPs da anstellen weiß ich nicht.
Dass sich das seit August so zieht ist aber eher ungewöhnlich bzw. zeigt dass es kein temporäres Problem ist was einfach so lösbar wäre. Die Probleme bei mir entstehen meist dadurch dass ein Knoten irgendwo ausfällt oder gewartet wird und durch die "Umleitung" entsteht an einem anderen Knoten dann zuviel Traffic.

 

[Engaged]

@TE hört sich ein wenig so an als wenn Vodafone nicht genug Schutzge... Äh peering Kapazitäten zur Telekom kauft

 

[scarabeusCB]

Grundsätzlich melde beim Origin Anschlussprovider eine Störung und beschreibe präzise welche Route gestört/dicht ist. Nach ein paar Werktagen sind diese Probleme dann oftmals auch behoben.

Top Antwort, und mit Handlungsempfehlung. Danke dafür.
Ich werde die Route tragen, und das so weitergeben - mal sehen wie weit ich komme.

 

[Tarnatos]

Ein MTR auf die IP des Main Servers wird dir zeigen an welchem Knotenpunkt es hakt.

 

[scarabeusCB]

Ein MTR auf die IP des Main Servers wird dir zeigen an welchem Knotenpunkt es hakt.

ok... Das sieht so aus, wie unten gezeigt und geht bis max hop hoch.
Ein Tip, wie ich damit weiterkomme?

traceroute to 84.141.XXX.XXX (84.141.XXX.XXX), 100 hops max, 60 byte packets 1 fritz.box (192.168.200.1) 0.693 ms 0.657 ms 0.990 ms 2 * * * 3 ip5886db4e.static.kabel-deutschland.de (88.134.219.78) 17.332 ms 18.512 ms 18.501 ms 4 83-169-156-24.static.superkabel.de (83.169.156.24) 19.879 ms 19.869 ms 24.443 ms 5 ip5886edaa.static.kabel-deutschland.de (88.134.237.170) 28.430 ms 25.567 ms 26.082 ms 6 ae8-100-xcr1.hac.cw.net (195.10.62.5) 25.487 ms 18.865 ms 18.827 ms 7 ae5-xcr1.ham.cw.net (195.2.24.181) 21.009 ms 13.939 ms 19.070 ms 8 ae2-xcr1.dus.cw.net (195.2.9.133) 36.100 ms 33.603 ms 23.302 ms 9 80.157.201.133 (80.157.201.133) 27.102 ms 25.957 ms 24.762 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *

 

[h00bi]

Starte das gleiche mal von einem anderen Anschluss aus ob du das bis zum Ende durch kommst.
Oder starte es in die Gegenrichtung.
Kannst mir auch gerne das Target per PN schicken.

der letzte hop 80.157.201.133 gehört zum RIPE und steht in Nürnberg (angeblich)

 

[seelo2010]

Den Bridge-Mode hast Du aktiviert am Modem?

 

[scarabeusCB]

Den Bridge-Mode hast Du aktiviert am Modem?

Ja.

Ergänzung (27. November 2018)

Starte das gleiche mal von einem anderen Anschluss aus ob du das bis zum Ende durch kommst.

Ich bin nicht vor Ort, und kann das aktuell nur über Devices machen, die ich Remote steuern kann.
Was genau meinst du eigentlich mit anderer Anschluss?
Anderes Gerät von dieser IP?
Gerät von anderer IP?

Oder starte es in die Gegenrichtung.
Kannst mir auch gerne das Target per PN schicken.
der letzte hop 80.157.201.133 gehört zum RIPE und steht in Nürnberg (angeblich)

Umgekehrt sieht es so aus. Interessant (für mich), dass man sich durchaus den Rest der Route zusammenreimen kann.
traceroute to 31.16.XXX.XXX (31.16.XXX.XXX), 64 hops max, 52 byte packets 1 fritz.box (192.168.150.1) 1.840 ms 1.148 ms 1.135 ms 2 62.155.241.68 (62.155.241.68) 6.019 ms 6.132 ms 5.890 ms 3 217.239.55.54 (217.239.55.54) 15.581 ms 16.259 ms 15.686 ms 4 80.157.201.134 (80.157.201.134) 15.502 ms 15.638 ms 15.936 ms 5 ae0-xcr1.ham.cw.net (195.2.9.134) 21.951 ms 21.869 ms 21.694 ms 6 ae7-xcr1.hac.cw.net (195.2.24.182) 25.319 ms 25.280 ms 25.307 ms 7 kabel-gw.hac.cw.net (195.10.62.6) 25.410 ms 26.029 ms 25.851 ms 8 ip5886edab.static.kabel-deutschland.de (88.134.237.171) 22.395 ms 22.125 ms 22.474 ms 9 83-169-156-25.static.superkabel.de (83.169.156.25) 27.286 ms 26.684 ms 26.941 ms 10 * * * 11 ip1f103b07.dynamic.kabel-deutschland.de (31.16.XXX.XXX) 38.842 ms !X 40.119 ms !X 50.290 ms !X

 

[h00bi]

Was genau meinst du eigentlich mit anderer Anschluss?

Einen nicht-VFKD Kabelanschluss hatte ich gemeint.
Also mal traceroute auf der Arbeit oder vom Handy aus oder bei Freunden je nachdem wo du es halt laufen lassen könntest.

 

[scarabeusCB]

Einen nicht-VFKD Kabelanschluss hatte ich gemeint.
Also mal traceroute auf der Arbeit oder vom Handy aus oder bei Freunden je nachdem wo du es halt laufen lassen könntest.

Ja habe ich jetzt mal gemacht, und liefert "ähnliche" Ergebnisse.
Auch die Traces von meinen beiden Standorten kombiniert (beide Richtungen) liefert erstmal sinnvolle Ergebnisse.
Der Trace von Remote -> Main findet den Endpunkt nicht, weil die Fritzbox dort auf den Request nicht antwortet. Also erhöht der Trace die TTL immer weiter, und findet keine Ende der Route.
Umgekehrt ist bei Remote ein Kabel-D Modem, das sehr wohl antwortet.
Starte ich den Trace jetzt bei Main sieht man die Abfolge im rechten Teil, 11 hops.
Ich habe den Trace von Remote jetzt umgekehrt angeordnet anhand der ähnlichen Server auf der Route (IP hat "1" als Unterschied). Diese Route wird wahrscheinlich bei "12" angekommen sein. Ein direkter Ping wird benantwortet und hat eine Laufzeit von 40ms.

Mir ist jetzt nicht klar, wie das jetzt bei der eigentlichen Frage hilft?
Die Traces haben vergleichbare Laufzeiten - war die Annahme, dass es hier auch "klemmt"?
Von Remote nach Main bekomme ich immer locker den maximal möglichen Durchsatz (von 11-12MBit/s) - mehr als 12 gibt die Leitung nicht her.
Umgekehrt bleibt der bei 2-3 MBit/s gedeckelt, obwohl hier 40MBit/s mal gingen über andere Routen VPN auch erreicht werden, und unter den aktuellen Bedingungen nicht.

Hat jemand eine Idee dazu?