Hi,
bei uns gab es letzten Donnerstag eine Großstörung ivm einem Vorleister der Westconnect. Seit dem ist auch IPv6 aktuell gestört, aber nicht bei allen Kunden. Wir sind zusammen mit dem Vorleister und einem Hersteller/Dienstleister dran.
Beiträge von kingpin42
-
-
Hi, schick mir mal deine Kundennummer per PN dann kann ich mir das morgen anschauen.
VG -
Das ging gestern bei T los und heute ist es bei euch
Bei DTAG war es eine fehlerhafte Konfiguration .
-
Ist VLAN 7 + PPPoE.
-
Mein Verständnis hat er.
Verträge sind immer von beiden Seiten zu erfüllen und wenn eine Seite Kommunikation für überflüssig hält, dann ist das genau der rationale Grund dafür, dem Vertragspartner nicht mehr zu vertrauen.
Wenn es sich so verhält, wie der TO oben beschrieben hat, ist es hier ja die DGN, die mit juristischen Tricks arbeitet.
Wenn es eine legale Möglichkeit gibt, den Vertrag wegen Nichterfüllung zu kündigen, dann soll er sie nutzen - dann weiß die andere Seite, dass "die Allgemeinheit" sich nicht alles gefallen lässt. Und es ist durchaus auch im Sinne der Allgemeinheit, wenn der Anbieter damit rechnen muss, dass Kunden abspringen, wenn die versprochenen Leistungen nach angemessener Frist nicht da sind.
Dann steht er halt ohne LWL da, und im schlechtesten Fall demontieren sie ihm einfach wieder den Anschluss oder verlangen dann eine saftige Gebühr wenn er später doch angeschlossen werden möchte.
-
Ich hatte mich ja zwischenzeitlich gefreut das es wieder ging. Das war aber leider nur ein temporärer Zustand.
Evtl eine Überlastung des Paid-Peerings zwischen Versatel und DTAG.
-
Wenn man denen dann auch einen direkten Kontakt zum 2. oder sogar 3. level Support geben würde.
Das brauchen sie gar nicht, das Einsenden von entsprechenden Logs und PCAPs genügt da schon vollends.
-
Da geht's ja gar nicht um Nachweise oder Schuldzuweisungen, sondern eine konstruktive Lösung zu finden
Ja, da wären ja jetzt die betroffenen Personen mit Ubiquity Hardware am Zug.
-
Achso. verstehe. Sprich das Problem mit Ubiquiti besteht wahrscheinlich mit dem BNG und nicht mit Infoblox. Tschjoa gut. Um das sinnvoll zu debuggen müsste irgendwer den EON Technikern ein Ubiquiti-Gerät spendieren. Sonst wird das vermutlich schwierig.
Da glaub ich noch weniger an Kompatibilitätsproblemen auf unserer Seite. Und wenn, wäre der Kunde derjenige, der nachweisen müsste, „unser“ DHCP Vorgang enthielte Fehler.
-
Das heißt man kriegt bei Dual-Stack von zwei Stellen jeweils eine IP? Infoblox für v4 und BNG für v6?
Der Pool, aus dem die v6 Prefixe und IA_NA Adressen stammen sind abweichend von den v4 Pools, ja. Sämtliche Kommunikation mit dem DHCPv4 findet aber trotzdem auch über denselben BNG statt. Du kommunizierst nie direkt mit dem DHCP.
-
Das wird mit dem Change zusammenhängen, wo EON IPv6 auf dem DHCP aktiviert hat, vermute ich. Das wurde wohl sehr gründlich mit AVM getestet. Aber leider offenbar gar nicht mit Ubiquiti. Wo das Problem nun liegt, vermag ich nicht zu sagen.
Nein, der Infoblox gibt nur v4 aus, v6 macht ausschließlich der BNG, sowohl die Vergabe der IA_NA, als auch des IA_PD Prefixes.
-
Zur Not könnte ich bei kleinen Tarifen auch PPPoE freischalten, sofern man unbedingt einen Speedport nutzen will.
-
Das hab ich mir gedacht, da dort ja auch jemand beschreibt, dass ein VoIP Client auf einem Handy auch funktioniert - aber nur im WLAN, nicht im Mobilfunk. Das passt genau zu deiner Beschreibung.
Eigentlich ist es ja auch kein Problem, wenn ein Renew mal ein bisschen zu früh oder zu spät kommt - solange es vor dem Ablauf des Leases kommt. Aber wenn jede ausbleibende Antwort auf ein minütliches Renew zu einem Log Eintrag führt, dann führt das zu Verwirrung ...
Die Route ist übrigens nicht mit einer CGNAT Adresse erreichbar.
Die Leasetime des DHCP Servers spielt bei uns eigentlich keine Rolle, das setzt/ändert der BNG und behält die Sessions sowieso im Blick. Aber auch der verhält sich RFC Konform. Wenn es jetzt, wie du sagst, Router gibt, die minütlich ein Renew anfordern, kommt da dann eben vom BNG aus irgendwann keine Antwort mehr, oder er wird sogar schon am MSAN verworfen.
-
Oh Mann. Da waren aber Experten am Werk. Keine Ahnung von IP Routing, aber Router kaufen, mit deren Konfiguration sie völlig überfordert sind ...
Das sehe ich leider häufig, auch im vermeintlich professionellen Umfeld.
Das Infoblox DHCP Cluster bei uns verhält sich jedenfalls strikt RFC Konform, ich hab leider keine USG oder andere Router von Ubiquiti zur Hand und könnte es direkt testen, jedoch habe ich mit "üblichen Verdächtigen" wie openWRT,*sense und Mikrotik keine Probleme mit kurzen Verbindungsabbrüchen durch Reconnects, wie dort beschrieben.
Telefonie ist auch mit öffentlicher IP im "Internet VLAN" erreichbar, da dort auch die Route zu den SIP-Proxys enthalten ist (10.199.27.0/24).
-
Kannst du zu meiner Frage zu den VLANs etwas sagen?
Ist es eigentlich zutreffend, dass man über VLAN 132 mittlerweile auch die SIP-Server erreichen kann?
Ich kann bei den zuständigen Kollegen mal nachfragen, aber nicht das ich wüsste.
-
Dann warten wir mal ab was sich in der Praxis mit Installationen ohne ONT tut ob das jemand funktionierend hinbekommt. Wäre ja schön wenn sich da bei EON etwas getan hat.
Das dürfte idr kein Problem sein. Je nach Ausbaugebiet kann ich das ONT provisionieren, bei neueren Gebieten ist dafür die Vitroconnect zuständig, da hab ich keinen Zugriff drauf.
-
Die Trennung muss nach genau 23:59 passieren, nicht nach 24H. Die verschiebt sich jeden Tag um 1 Min nach hinten. Ansonsten hast du immer 2 drin, die eigene und die vom ISP
https://www.ip-phone-forum.de/threads/avm-un…rennung.308289/
Dann trennt halt der Provider für einen, macht doch keinen Unterschied.
-
Hi,
irgendwas scheint mit dem Forum hier nicht richtig zu laufen, bekomme folgenden Fehler (Chrome und FF probiert):
ZitatWarning: Failed loading Zend extension 'ioncube.so' (tried: /usr/lib/php/20200930/ioncube.so (/usr/lib/php/20200930/ioncube.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/ioncube.so.so (/usr/lib/php/20200930/ioncube.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Ist das Problem schon bekannt ?
-
Die von der Telekom? Die sind so von der BNetzA so genehmigt.
Zum anderen, wieso sind das Mondpreise? Kennst Du die genaue Kalkulation und mit welchen Kostenanteilen dort gerechnet wurde?
Das Glasfasernetz der DTAG ist nicht reguliert, nur die CuDa und deren, darauf aufbauenden Produkte.
-
Auch hier muss ich mal eine Lanze für die Telekom brechen, das Kupfernetz am Laufen zu halten kostet massiv viel Geld. Gerade in den alten Bundesländern liegt noch so viel altes Papierkabel welches einfach in die Jahre gekommen ist.. und die Gebühren für Vorleister/letzte meile gehen aber seit Jahren immer weiter zurück. Da kommt natürlich i-wann die Frage wer soll das bezahlen ?!
Im Gegenteil, die Vorleistungsgebühren, auch für die CuDa TAL, steigen. Wie der Artikel zeigt, in einem eher ungerechtfertigten Maße.
