[WORKAROUND] EFW2.4: Uplink Failover funktioniert nicht

    Hallo Allerseits,

    Ich bin mir nicht sicher ob ich bei der Konfiguration was vergessen habe (bin IPcop Umsteiger), aber ansich sieht ja so weit alles ganz logisch aus.

    Ich habe 2 DSL Leitungen (T-Com & M-Net). Beide Uplinks sind eingerichtet und funktionieren. Der M-Net Account ist mein Hauptaccount und ist so konfiguriert, dass er bei Ausfall auf die T-Com-Leitung umschaltet. Die Konfiguration kann man sich im angehängten .jpg anschauen.

    Das Problem, kurz dargestellt durch 2 Tests:

    1.

    - EFW rebootet. Beide Uplinks "UP"
    - Hauptlink (M-Net) manuell abgeschaltet (/Network/Interfaces/Uplink Editor im Web-Interface)
    - Hauptlink zeigt Status "INACTIVE"
    - Der Backup-Link übernimmt. Alles paletti

    2.

    - EFW rebootet. Beide Uplinks "UP"
    - DSL-Kabel aus dem Splitter rausgezogen
    - Hauptlink zeigt Status "CONNECTING"
    - Nichts passiert. Backup-Link übernimmt NICHT

    Wenn ich alles so lasse wechselt der Status des Hauptlinks zwischen "CONNECTING" und "INACTIVE" hin und her. Der Backup-Link ist währenddessen "UP". Internet-Zugriff ist nicht möglich.

    Hier kommt aber jetzt das schlimmste: Wenn ich den Stecker wieder reinstecke kommt der Hauptlink nicht wieder hoch. Angezeigt wird abwechselnd "CONNECTING" und "DEAD". Das hier taucht immer wieder im Log auf:

    An dieser Stelle hilft nur noch ein Reboot.

    Mittlerweile hab ich es sogar einmal fertiggebracht, dass der Failover funktioniert. Ich habe die folgende Policy-Route aufgesetzt:

    Source: GREEN, Destination: ANY, Service/Port: ANY/ANY, Route via: Main uplink, Use backup link if uplink fails: checked

    - Hauptlink manuell abgeschaltet -> Failover funktioniert nach ca. 10 Sekunden
    - Hauptlink wieder eingeschaltet -> Routing geht wieder auf Hauplink zurück
    - DSL-Kabel rausgezogen -> Failover funktioniert nach ca. 30 Sekunden
    - DSL-Label wieder reingesteckt -> Der Hauptlink komt wieder "UP" und die Pakete gehen wieder durch.

    Alles perfekt. Nur als ich dasselbe eine Stunde später nochmal probiert habe gings wieder nicht. Geändert hab ich zwischendurch nichts.

    Ich hab noch eine andere Policy-Route die allen Traffic aus "RED" durch den Backup-Link schickt. Irgendwann kam dann aber plötzlich "RED"-Traffic durch den Hauptlink. Nach einem Reboot war dann wieder alles normal.

    Bei weiteren Tests habe ich noch festgestellt, dass immer wenn ich den Link automatisch überprüfen lasse ("Check if these hosts are reachable". Ausprobiert hab ich
    http://www.google.com, http://www.google.com & http://www.yahoo.com, 8.8.8.8) auf jeden Fall der Link irgendwann "DEAD" ist. Google ist natürlich währenddessen erreichbar. Und ein Failover findet auch nicht statt.

    Ich verzweifle hier langsam. Was mache ich verkehrt?? Ich hab die Endian FW eigentlich hauptsächlich wegen dem Failover aufgesetzt. Zu diesem Zeitpunkt hatte ich die 2. Leitung noch nicht geschaltet, hab mich aber darauf verlassen dass alles funktioniert wenn sie dann da ist. Seitdem ist mir die EFW irgendwie ans Herz gewachsen, so dass ich nicht schon wieder umkonfigurieren will...

    Meine Hardware ist ein Intel ATOM Pine Trail D mit ICH8M Chipset und 4 Realtek Gigabit NICs, 2GB RAM und einer 120GB HD

    Wens interessiert: Ich habe das ganze auch als Bug gemeldet: http://bugs.endian.com/view.php?id=3015

    Zitat von "akurz"

    Ich verzweifle hier langsam. Was mache ich verkehrt?? Ich hab die Endian FW eigentlich hauptsächlich wegen dem Failover aufgesetzt. Zu diesem Zeitpunkt hatte ich die 2. Leitung noch nicht geschaltet, hab mich aber darauf verlassen dass alles funktioniert wenn sie dann da ist.
    Hier kommt aber jetzt das schlimmste: Wenn ich den Stecker wieder reinstecke kommt der Hauptlink nicht wieder hoch. Angezeigt wird abwechselnd "CONNECTING" und "DEAD". http://bugs.endian.com/view.php?id=3015


    Hallo im Forum.
    Was du da beschreibst kenne ich nur zu gut.
    So ca. alle 30-60 Sekunden bekam ich nach einem DSL-Resync eine neue DSL-IP, aber die Endian zeigte diese zwar an aber versagte trotzdem die Funktion.
    Auch ich nahm die Endian ausschließlich wegen dem Failover.
    Offenbar schwächelt die Endian bei der direkten DSL-Modem Bedienung. Ich benutze als Backupzugang einen DSL-Anschluß über Arcor.
    Wenn das DSL-Modem den DSL-Link verliert und später wieder aufbaut, ist die Endian einfach zu grottendämlich das zu erkennen und korrekt zu reagieren.
    Ich probierte auch schon viele Stunden lang diesem Problem Herr zu werden. Es ging nicht mit der Endian.

    Allerdings löste ich das Problem wie folgt:
    Da jeder drittklassige Router besser mit DSL umgehen kann nahm ich einen alten DSl-Router (Draytek) und schaltete diesen nach dem DSL-Modem an.
    Der Draytekrouter erkennt zuverlässig jede DSL-Unterbrechung und baut die Verbindung selbständig immer wieder neu auf.
    Den Ausgang des Routers (Router unbedingt vorher auf eine ganz andere DHCP-IP-Ebene stellen) schloss ich an der Endian an und stellte die Endian auf DHCP-Eingang.(Wie beim Kabelmodem auch). Jetzt funktioniert das Failover richtig gut, es zählt für die Endian rein nur noch das Anpingen der Webseiten die man ausgesucht hat.

    Da reine DSL-Modems eh selten wurden kannst du ja auch dein (eventuell Router/Modem) auf Routerbetrieb umstellen und dann klappts.
    Praktisch ist es sogar das der vorgeschaltete DSL-Router problemlos durch die Endian zu erreichen ist.

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hallo Grenzwert,

    Kannst du mir dein Setup nochmal erläutern, bitte? Du hast also einen extra Router vor der Endian und nutzt den sozusagen als Gateway, richtig?

    Gefällt mir zwar nicht (ein vernünftiger Firewall/Router sollte das packen), aber ich würd's mal probieren.

    BTW: Beide IPs sind statisch, also sollte es mit einer gewechselten IP nix zu tun haben. Ich bin grad unterwegs und hab nicht so viel Zeit, aber wenn ich wieder zuhause bin schreib ich noch was rein. Ich hab nämlich noch weitergetestet und teilweise haarsträubend unlogische Fehlerbilder entdeckt.

    Gruß, Alex

    Hallo Alex,

    den kl. Router schaltete ich davor um das DSL Handling sauber hinzubekommen. Das ist ja in 2.3 und 2.4 fehlerhaft.

    Aber seit heute gabs die schlimme Erkenntniss das das Failover in der V2.4 nur einmal funktionierte.
    Zufällig gab es heute einen mehrstündigen Ausfall meines Hauptzugangs und die Endian schaltete selbständig auf den Backupzugang um.
    Allerdings, als nach Stunden der Hauptzugang wieder on war, schaltete die Endian nicht mehr zurück.
    Erst durch mein Eingreifen mit reconnect wurde der Hauptzugang wieder benutzt.
    Also das hatte mit der V2.3 richtig funktioniert. Echt seltsam was da abgeht.
    Ich dachte immer das das DSL-Problem daran lag das Arcor hier den Zugang änderte, weil es davor früher schon korrekt mit der V2.3 funktioniert hatte.
    Aber da du ja nicht bei Arcor bist liegt das Problem vielleicht nicht mehr nur am DSL Wiederanwahlproblem sondern auch an der V2.4.

    Was mich noch interessieren würde ist die erweiterte Einstellung : Wiederverbindungs Timeout
    Was bedeutet das genau und welche Zeiteinheit wird im Wertebereich verwendet?


    Gruß, Jochen

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hallo Jochen,

    ja, einmal krieg ich's auch immer hin, dann ists wieder vorbei. Das Failover macht ganz schlicht was es will, aber garantiert nicht was es soll. Am Sonntag hatte ich meine EFW mal wieder so weit, dass sie einen Failover recht gut hinbekam. Ich hatte einen Ping auf http://www.google.com laufen und hab bei der Hauptleitung den Stecker gezogen. Gab ein paar Timeouts und dann gings weiter auf Leitung 2. Stecker wieder rein und zurück gings auf Leitung 1. Tolle Sache, wäre da nicht ein kleiner Haken: Ich hab meinen HTTP Proxy transparent auf GREEN laufen. das funktioniert grandios so lange Leitung 1 online ist. Passiert ein Failover lehnt der Proxy alle Requests von jedem Rechner im Netz ab. Im Log stehen dann haufenweise TCP_DENIED Ereignisse drin. Versteht sich von selbst, dass das mit den Regeln im Proxy absolut nix zu tun hat, da die ja auf Leitung 1 perfekt funktionieren. Ich hab trotzdem mal alle Block-Regeln ausgeschaltet und nur eine einzige ALLOW ANY/ANY drin gelassen. Funktioniert auf Leitung 1. Bei Failover wird wieder jede Anfrage von jeder IP geblockt. Sobald ich den Proxy ausschalte geht alles auch auf Leitung 2. Das soll mir mal einer plausibel erklären.

    Das war, wie gesagt am Sonntag. Montag morgen bin ich weggefahren und erst vor einer halben Stunde wieder daheim angekommen. Geändert habe ich in der Zeit nichts (logisch, da ich ja nicht da war). Da ich ja absolut nichts anderes mit meiner Zeit anzufangen weiß, bin ich als ersten in den Keller gegangen und hab den Stecker von Leitung 1 gezogen. Ergebnis: Failover funktioniert wieder nicht.

    Echt, schön langsam geht mir mit der EFW die Geduld aus. Die Tatsache, dass so viele offensichtliche Fehler in diesem Produkt derartig lange überleben bringt mich zum Nachdenken. Schließlich ist eine Firewall ein sicherheitsrelevanter Teil der Infrastruktur. Wie viele versteckte Mängel mag es da noch geben, die meine Umgebung eventuell gefährden? Ich denke ich werde mich nochmal auf die Suche nach Alternative machen. Die Vyatta FW hab ich mir mal angeschaut, aber Donnerwetter, die schaut villeicht kompliziert aus... Ich weiß, das hier ist wohl nicht unbedingt der richtige Platz um sowas zu fragen, aber gibts noch andere freie Alternativen die Failover beherrschen???

    Betreffs des Wiederverbindungs-Timeouts: Das ist die Zeit, die die EFW wartet, bis sie nach einem Leitungsverlust einen neuen Einwahlversuch startet. Die Zeiteinheit sind Sekunden. Über den Standard-Intervall schweigt sich die Dokumentation ja leider aus...

    Gruß,
    Alex

    Noch was: Ich könnte beim Bug-Tracker etwas Unterstützung gebrauchen. Im Moment scheint das keinen zu interessieren. Wenn also jemand anderes ebenfalls mit diesem Problem zu kämpfen hat wär's nett wenn ihr mir eine kurze "Me Too" confirmation posten könntet. Das Ticket ist hier: http://bugs.endian.com/view.php?id=3015

    Danke,
    Alex

    Hallo Alex, klingt ja wirklich haarsträubend.

    Aber die Endian hat sicherlich auch viele gute Seiten, aber den wahren Charakter erkennt man erst nach etwas Zeit.
    Ich suchte auch schon Alternativen, na ja - merkst ja das ich die Endian weiterbetreibe.

    Nach meinem gestrigen AHA-Erlebnis des fehlenden zurück-Failovers habe ich mittels SSH und reboot Linux neu gestartet.
    Heute dann von Hand die Failoversituation provoziert, sprich meinen Hauptlink so gestört das mein Kabelmodem zwar an und mit der Endian connectet ist, aber die Verbindung zum Internet verlor.
    Diesesmal funktionierte es wie gewohnt das erst auf DSL (hinter dem Minirouter) geschaltet wurde und später, nachdem ich den Hauptlink wieder funktionsfähig stöpselte, anstandslos zurück auf das Kabelmodem wechselte.

    Von dem her funktioniert bei mir das Failover doch. Natürlich mit der Einschränkung der fehlerhaften DSL-Wiedereinwahl

    Warum bei dir der Proxy so rumzickte entbehrt ja wirklich jeder Logik. Green ist green und hat Vorrang.

    Wäre es bei dir möglich das es Probleme mit den Schnittstellentreibern gibt? Welche Chips hast du verbaut? Auch PCIe ? Die zicken schon mal gerne.

    Ansonsten könntest du wirklich mal 2 Minirouter für die reine DSL-Anwahl vorschalten. Eventuell bringt das etwas Licht in das Dunkel.

    Gruß, Jochen

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Zitat von "akurz"

    Noch was: Ich könnte beim Bug-Tracker etwas Unterstützung gebrauchen.


    Soweit war ich auch schon vor einigen Monaten... :D In Italien malen die Mühlen sehr langsam.

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hallo Jochen,

    Gut, dann lassen wir die Mühlen mal mahlen. Bis dahin hat mir dein Workaround schon einmal sehr weitergeholfen. Ich hab mit 2 kleine Modem/Router besorgt und deinem Vorschlag entsprechend aufgesetzt. Bisher (!) läuft alles so wie's soll. Wenn ein Link weg ist, ist er "DEAD" und die Backup-Leitung übernimmt. Auch der Proxy macht derzeit (!) keine Probleme. Natürlich werde ich das morgen nochmal testen. Und übermorgen. Und......

    Jedenfalls vielen Dank für den Denkanstoss!

    Zu deiner Frage: Ja, ich hab auch 5 von den PCI-e Realteks drin. Die liefen ja erstmal gar nicht, bis ich nen neuen Treiber eingebunden hatte. Anscheinend ein Fehler im Kernel. Aber nun mit dem neuen Treiber scheinen die Chips eigentlich problemlos zu laufen. Auch hohe Netz-zu-Netz Last können die problemlos ab. Ich denke der Fehler ist weniger in der Hardware zu suchen. Das Problem ist, dass die Büchse bei PPPoE Leitungsausfall erstmal Probleme hat überhaupt zu merken, dass sie offline ist. Danach gibts dann anscheinend beim setzen der Routen auf die Gateways trouble. Die DNS-Settings spielen wohl auch noch mit rein. Im großen und ganzen ist das Failover in Verbindung mit PPPoE gründlich im A*sch. Der ganze Workaround - selbst wenn er langfristig funktioniert - hinterlässt einen faden Beigeschmack. Die zwei Billigst-Router stehen nun an der ersten Linie zum Netz und sind der erste Angriffspunkt. Von da aus hab ich dann einen wunderbaren Vektor auf die Firewall selbst. Da darf ich gar nicht drüber nachdenken...

    Na wie auch immer. Deutschland hat gewonnen und mein Failover geht auch. Da bin ich doch erstmal zufrieden :)

    Gruß,
    Alex

    Hallo Alex, wie schön das es trickreich schon mal funktioniert.

    Das Treiberproblem wäre in Frage gekommen als dein Proxy das Failover nicht wollte.
    Ich selber benutze wegen den Treiberproblemen nur PCI Netzwerkchips.
    Da aber wohl das Kernproblem bei der DSl-Anwahl zu suchen ist hat es ja mit Ethernet nichts mehr zu tun.
    Ich vermute einfach das die Endian nach einem Failover nicht mehr mitbekommt wann eine DSL-Anwahl erfolgreich war.
    Daher versucht sie es wieder und wieder und gibt irgendwann auf.
    Vermutlich funktioniert das DSL-Einwahlhandling der Endian in Italien perfekt.

    Ich kann absolut kein Sicherheitsrisiko darin erkennen das ein vorgeschalteter Router die Anwahl übernimmt.
    Schließlich greift rundweg alles wie gewohnt in der nachgeschalteten Fierewall.

    Weißt du - ein Kabelmodem verhält sich zum DSL+Router sehr ähnlich.
    Das Kabelmodem routet per DHCP auf max. einen Client durch.
    Und zwar absolut alles an Datenverkehr - 100%. Also transparent wie nur was. Hierbei gibt es Dank der Firewall auch kein Sicherheitsrisiko.
    Und auf deinem vorgeschalteten Router ist es mit Sicherheit genauso langweilig wie auf jedem anderen DSL-Router an den Millionen von Anschlüssen.
    Ping-Response wirst du sowieso dort aus haben und die Oberfläche paßwortgeschützt. Fernzugriff deaktiviert und eigentlich kann dort absolut alles aus sein bis auf DHCP-Server,
    Wanresponse und DSL-Anwahl. :)

    Gruß, Jochen

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hi Jochen,

    natürlich hast du mit den Sicherheitsbedenken recht, trotzdem stört mich das alles ein wenig. Auch hab ich festgestellt, dass ich durch den zusätzlichen Hop massive Probleme mit VoIP bekommen habe. Hab ich mittlerweile aber auch behoben.

    Sag mal, hast du bei deinen Routern NAT an? Ohne NAT bekomm ich keine Zugriffe von aussen geforwarded. Meine Config sieht nun so aus:

    - NAT an
    - EFW in der "DMZ" Zone des Routers

    Scheint so weit zu funktionieren, aber noch ein NAT Device macht halt Probleme, siehe VoIP. Irgend eine Idee wie ich da ohne NAT weiterkommen könnte?

    Gruß,
    Alex

    P.S.: Sorry, dass ich dich so auf Trapp halte mit meinen Problemen, aber du bist bisher der einzige Ansprechpartner / Leidensgenosse den ich habe.

    Zitat von "akurz"

    Übrigens:
    Schön billig, aber ein Interface zum davonlaufen ;)


    Hallo Alex,

    boah... habe aus Neugierde draufgeklickt gehabt. Und jetzt habe ich Augenkrebs. :)
    Deine 2 Anwahlrouter sind auch optisch zum Davonrennen.

    Ich sah mal in meinem vorgeschaltetem, betagtem Draytek nach NAT, aber wie es aussieht ist das immer eingeschaltet. Ich kanns gar nicht auf classic routing umschalten.

    Die DMZ hatte ich damals auch getestet, kam aber davon wieder ab. Die WAN-IP wurde dabei sogar zur Endian durchgereicht, aber im Ergebniss funktionierte es nicht richtig.
    Ich kam auch nicht mehr auf den Router drauf.
    Von demher funktioniert es mit NAT bei mir wunderbar, auch mit VoIP.
    Warum es bei dir zickt weiß ich nicht, ich weiß lediglich aus Erfahrung das Billigrouter einen Grund haben das sie billig sind.

    Ich habe mal eine handvoll Billigrouter getestet, von D-Link bis Zyxel. Bei jedem zweiten Billigrouter funktionierte das VoIP nicht mehr.
    Und es war kein Konfigurationsfehler, ich probierte natürlich alles aus warum die Ports nicht durchkamen. Also wundert mich an diesen Kisten nichts mehr.

    Und ganzheitlich gesehen hast du natürlich Recht. Es ist müßig nur an den Symptomen (falsche DSL-Anwahl) rumzudocktern, wo doch die Ursache beseitigt gehört.(Endian).
    Ich würde mir den Zusatzrouter auch gerne sparen, der hängt zwar nur im Keller an der Wand - aber ist trotzdem 1000mal hübscher als deine beiden Cyborgs ... :lol:

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hast schon recht. Im betrieb sehen die echt ein bisschen Zylonen-mässig aus :)

    Abgesehen vom VoIP hat bisher nichts gemuckt und mit eingetragenem STUN Server flutscht das auch wieder. Somit ist jetzt für mich erstmal alles grün. Im Bug-Tracker hab ich noch einen weiteren Kommentar geschrieben, aber interessieren tut's erstmal niemanden. Ist schade drum, ehrlich. Kann man halt nix machen. In der nächsten Zeit werden die Italiener eh erstmal mit Trauern beschäftigt sein, jetzt wo sie aus der WM geflogen sind :)

    Gruß,
    Alex

    Schönes Foto, Alex.

    Die Zylonenaugen passen sogar ganz gut dahin. :D

    Auf den ersten Blick würde ich sagen das die Modems ein Wärmeproblem haben müßten.
    Wenn jedoch die Luft im Rack ventiliert, dann natürlich nicht.

    Wie schnell ist eigentlich dein DSL ?


    Gruß Jochen

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hi Jochen,

    Das Dingen oberhalb der Modem/Router ist nur ein Patchpanel. Da ist zwar die Blende 1HE hoch, aber direkt dahinter wird die ganze Angelegenheit schmaler. Über den Modems sind gut 2 cm Luft. Und direkt oberhalb des Panels sind 4 120er Lüfter die die Luft aus dem Schrank saugen. Ist ganz schön zugig wo die stehen ;)

    Die Frage nach dem DSL ist interessant. Ich wohne in einem Kaff wo die T-Com nur 2000er DLS Leitungen verkauft, und nicht mal die 2000 garantieren sie. 1500 wären wahrscheinlicher. Liegt an der Entfernung zum nächsten Verteiler. Naja, jedenfalls hatte ich jahrelang 2 Leitungen in 2 verschiedenen Häusern, verbunden per Richtfunk. Das andere Haus habe ich nun verkauft und mir noch einen Anschluss in mein Haus legen lassen. Diesmal von M-net. Die verkaufen DSL 6000, aber logischerweise hab ich mir keine drastischen Unterschiede erwartet, da M-net zwar eigene Infrastruktur hat, allerdings erst hinter dem Verteiler. Somit liegen also dieselben Beschränkungen vor wie bei T-Com. Der Telekom-Techniker, der im Auftrag von M-net die Leitung geschaltet hat meinte sogar, dass die beiden Leitungen wahrscheinlich übersprechen würden und ich mit permanenten SYNC Problemen zu rechnen hätte. Lange Rede, kurzer Sinn: Während bei der T-Com-Leitung bei ca. 200kB/sec Schluss ist, liefert die M-net-Leitung stabil zwischen 800 und 1000 kB/sec. Zu jeder Tageszeit und auch wenn ich beide Leitungen gleichzeitig glühen lasse. Versteh ich zwar nicht, aber ich werd mich mal nicht beschweren ;)

    Ums nochmal ganz kurz zu machen: Ich hab 1x DSL 2000- und einmal DSL 6000+.

    Gruß,
    Alex

    Zitat von "akurz"

    Versteh ich zwar nicht, aber ich werd mich mal nicht beschweren ;)


    Hi Alex,

    das ist einfach. Die Telekom schaltet Fixrate DSL2000, obwohl die techn. Grenze deiner Leitung ohne Entstörung offenbar bei ca. DSL11.000 liegt.
    Das ist typisch Telekom, sie spart sich mit dieser Methode Servicekosten für den Fall, das mal eine kleine Signalstörung auftritt.
    Denn die Telekom läßt so viel ungenutze Reserve auf deiner Leitung (TAL) das es schon einer sehr großen Störung bedarf um diese in die Knie zu zwingen.
    Oder anders gesagt : Die Telekom verarscht dich mit ihren starren Schaltungsgrenzen nach Kontes Orka, die technisch schon lange überholt sind.

    M-net jedoch hat offenbar sehr wohl eigene Technik bei euch - der DSLAM ist bestimmt von M-net.
    M-net schaltet, wie der Rest der Welt auch (ausser Telekom ohne RAM-Projekte oder >6M), rateadaptiv. Das bedeutet die Modems handeln unter sich aus wie schnell der Betrieb auf deiner Leitung möglich ist. Auch hierbei wird eine kleine technische Reserve gelassen um stabilen Betrieb zu ermöglichen.
    Vermutlich ging es sogar noch schneller wenn du ein sehr gutes Modem und eine Leitungsentstörung benutzt.

    Gruß, Jochen

    Kabelzugang mit 400/20, Ergänzung mit VDSL100/40.

    Hi Jochen,

    versteh ich ja alles aus technischer Sicht. Warum die Telekom-Leute aber im Brustton der Überzeugung behaupten, dass selbst 2000 am äußersten Rand der technischen Möglichkeiten ist erschließt sich mir nicht. Aber wie auch immer: Ich bin erstmal happy. Bisher war ja ich nicht gerade verwöhnt ;)

    Gruß,
    Alex

    Hallo,

    es ist nicht unbedingt die Schuld der Telekom, dass sie dir kein gescheites DSL schaltet.
    Ich hatte es schon mehrmals bei Kunden, dass unterschiedliche TALs gravierend unterschiedliche Leistungen hatten.

    Dies liegt zum einen daran, dass die Leitungen nicht immer alle im selben Strang liegen und die selbe Route zum HVT haben, und zum Anderen kann bei deiner T-Com Leitung auch einfach das Kabel oder ein Patch nicht ganz in Ordnung sein.

    Dass die T-Com immer ein wenig mehr Reserve lässt wie die Mitbewerber ist schon richtig, allerdings sicherlich nicht in dem Ausmaß.