Danke für die Rückmeldung und die Klarstellung der Ursache. Respekt. Macht nicht jeder.
Beiträge von frank_m
-
-
Nee, MAC braucht man wohl nicht. Aber GPON Serial und ONT Installationskennung.
-
Ich kann deinen Frust verstehen, aber ich werde immer sehr vorsichtig, wenn ich "Beschwerde" und "BNetzA" lese. Der Grund ist, dass das in den seltensten Fällen hilft, da die Ursache entweder deutlich vorher beseitigt werden kann, oder gar nicht. Gar nicht scheidet in den meisten Fällen aber aus, da keine adäquate Alternative zur Verfügung steht.
Wir hatten durchaus einige IPv6 Ausfälle zu beklagen, aber das war immer ein überregionales Problem, sprich: Es waren mehrere davon betroffen. Deiner Schilderung nach existiert das Problem schon einige Zeit, aber man hat von anderen nichts gehört. Das ist ein Hinweis auf ein individuelles Problem, und damit steigt die Wahrscheinlichkeit für ein Problem auf deiner Seite.
Um das auch noch mal deutlich zu sagen: Der Kundenservice deckt die Mainstream Endgeräte ab. Es ist völlig ausgeschlossen, dass jeder Hotline Mitarbeiter die IEEE und RFC Specs auswendig kennt und weiß, wie er sie auf OpenSense umzusetzen hat. Anders ausgedrückt: Wer den Pfad der Tugend verlässt, muss sich selber zurecht finden.
Aufgrund der Vielfalt der ausprobierten Geräte erfülle ich die Schnittstellenspezifikationen der DG, wodurch ich diese mögliche Ursache des Problems ausschließen kann.
Woran machst du das fest? Nur an der Anzahl der Geräte? Sehr gefährlich!
Da du ja wirklich dringend auf die IPv6 Verbindung angewiesen bist, würde ich an deiner Stelle auf jeden Fall alles dran setzen, das Problem zu lösen. In deinem Fall heißt:
- Teste es unbedingt und ohne jede Rückfrage mit einem Router, der nachweislich problemlos und ohne Konfigurationshürde an einem DG Anschluss funktioniert! Ich würde eine Fritzbox 7590 empfehlen. Danach sehen wir weiter.
Zu den von dir beschriebenen Routing Problemen wären einige weitere Diagnose Informationen interessant. Was genau bedeutet "keinen IPv6 upstream Gateway mehr zugewiesen bekommen"? Wo endet ein traceroute aus dem Internet auf deine Adressen (FB Adresse, Adressen aus dem /56 Prefix)? Wo enden traceroutes aus deinem Netz zu z.B. Heise?
-
So wie es scheint, sind die Funktionen zum Setzen der GPON Serial und der MAC-Adresse bei einer 5530 fiber mit gesteckten GPON-SFP Modul bei FRITZ!OS 7.26 nicht wirklich funktional.
Das kann aber irgendwie auch nicht sein, denn es gibt ja Anleitungen, die 5530 am Telekom Glasfaser Anschluss in Betrieb zu nehmen ohne Rediscover. Dabei braucht man ja genau diese Werte.
-
Warum das nur mit 7.26 funktioniert, weiss ich auch nicht.
In der Software müssen Authentifizierungsinformationen enthalten sein, die es dem SFP Modul erlauben, einen GPON Link aufzubauen. Diese Information fehlt in neueren Versionen offensichtlich, denn die sind ja nicht in der Lage, einen physikalischen Link aufzubauen. Ein Abgleich der Versionsinformationen kann also noch nicht stattfinden, da es keine Verbindung dafür gibt.
-
Was scheitert denn noch? Das mit den Pings habt ihr doch hinbekommen? Dann müssen noch die Serverdienste entsprechend eingerichtet werden, so dass sie aus dem Internet erreichbar sind, und dann die Firewallregeln für diese Server.
-
Hallo,
du musst eine VLAN ID bei der Telefonie Verbindung eintragen, aber definitiv keine Benutzerdaten. Vermutlich brauchst du auch den Haken bei "PVC" nicht, das wäre aber herauszufinden.
-
Naja, solange sich DG an die Standards hält, ist es eher Sache des Routerherstellers, die Kompatibilität sicherzustellen. Und da AVM, Ubiquiti, Lancom, Cisco und was wir sonst noch so alles hier im Forum finden kein Problem mit der Umstellung hatten, dürfte relativ klar sein, wer hier aktiv werden muss.
-
aber derzeit "IPv4 und IPv6, IPv6 bevorzugt".
Du stellst Probleme bei der Aktivierung von IPv6 fest und bevorzugst IPv6 für die Verbindung?
Ich bin mir sicher, dass deine Konfiguration für das Problem verantwortlich ist. Beim "DG Router" werden andere VoIP Server verwendet, als beim "kundeneigenen Router". Folglich musst du sicherstellen, dass die DG Anmeldung über den 2. PVC erfolgt und das dort kein IPv6 benutzt wird. Außerdem muss sichergestellt sein, dass die richtige VLAN ID für den 2. PVC genutzt wird, und das ist vermutlich nicht 362.
Ich würde folgendes vorschlagen:
- IPv6 aktiv
- VLAN ID für Telefonie 330 mit PBit 0
- DSL VoIP accounts mit "Anmeldung immer über eine Internetverbindung"
- DG VoIP accounts ohne "Anmeldung immer über eine Internetverbindung"
- in beiden Fällen IPv4 als Protokoll
-
Und mit dem guten adam2 Prompt und setenv kann man schöne Dinge machen. Wenn man weiss, was man tut - wenn nicht, dann wird's hässlich.
Ja, das stimmt. Aber werden im adam2 Environment Einträge durch normale Firmware-Updates modifiziert? Ich dachte immer, da liegen die Sachen, die so ziemlich jeden Werksreset und jedes Update überstehen sollen.
-
Es ist tatsächlich merkwürdig, dass die erforderlichen Daten in den Folgeversionen nach 07.26 nicht mehr enthalten sind. Vielleicht deutet es darauf hin, dass es mal ein spezifisches Branding für DG Boxen geben wird. Aber ich vermute stark, wenn die DG jetzt den Prozess etabliert, dass in der Folge auch in den zukünftigen Versionen die erforderlichen Infos für den GPON Zugang drin sind. Interessant wäre ja noch zu wissen, welche Info das ist.
-
Danke für den Tipp. Wenn ich die VLAN ID auf 330 ändere, dann lassen sich gar keine SIP-Accounts mehr verbinden, auch nicht die von meinem bisherigen DSL-Anbieter.
Das lässt sich vermutlich ändern, indem du in den DSL VoIP Accounts einen Haken bei "Anmeldung immer über eine Internet Verbindung" setzt.
Und da auch direkt die Frage: Wie hast du den Haken bei den anderen VoIP Accounts gesetzt?
-
dann müssen wir warten, bis die 7.27 Physik aufbauen kann und noch mal testen.
Das wird nichts. Noch mal: Es ist normal, dass keine physikalische Verbindung angezeigt wird. Die Box verfügt nicht über die Infos, den GPON Stream zu ver/entschlüsseln. Vermutlich wird dir im Glasfaser-Status eine gelbe Linie angezeigt, richtig? Da fehlt kein Licht, da fehlen die passenden Zugangsdaten.
Das Ziel der Eingaben der Daten des anderen ONTs ist es doch, genau diese physikalische Verbindung aufzubauen. Es muss also quasi erst mal nicht funktionieren, damit die Versuche überhaupt Sinn machen.
-
schrieb ich, ja. Die 7.27 stellt keine Physik her,
Aber genau darum geht es ja. Natürlich stellt die Version ohne die entsprechenden Parameter keine Verbindung her. Die Frage ist, ob man sie davon überzeugen kann, indem man die Parameter eingibt.
-
Hier sind die Default Policies bei UDM beschrieben:
-
Versuche es mal direkt: http://fritz.box/support.lua
-
elnx: Genau so ist es. Beim Betrieb "kundeneigener Router" wird "vor dem ONT" die VLAN ID 362 benutzt, die am Kupferausgang rausgefiltert wird. Kundeneigene Router am Kupfer des ONTs brauchen sich mit VLANs nicht mehr abzugeben.
Im Modus "DG Router" ist es anders. Dort werden "vor dem ONT" die VLAN IDs 360 und 330 benutzt, wie bei HubeBube beschrieben, aber die bleiben dort auch "nach dem ONT", also am Kupfer erhalten. Jedenfalls wird die DG 7590 mit den entsprechenden VLAN IDs konfiguriert.
Das ist bei AON so, aber ich könnte mir gut vorstellen, dass es bei GPON auch so ist.
-
Ich kann mir gut vorstellen, dass sich die Standardregeln ändern, wenn man die Policy umstellt. Ich vermute, das ist bei dem Kollegen der Fall, denn er schreibt in seiner Anleitung:
ZitatHierzu bei „IPv6 WAN eingehend“ erst entsprechende Regeln für jedes Zielgerät und den entsprechenden Ports erstellen. Falls es mehrere sind, können auch Portgruppen oder Adressgruppen erstellt werden.
Danach eine Regel erstellen, die jeglichen IPv6 Zugang auf allen Ports verbietet.
Der fett gedruckte Teil wäre eigentlich nicht nötig, wenn die Default Policy "drop" ist, sehr wohl aber, wenn sie "accept" ist. Bei default Policy accept hingegen sind die Standard-Regeln, die ihr hier postet, unnötig, und können wegfallen. Es würde zuverlässig erklären, warum ihr davon ausgegangen seid, dass die Firewall offen ist für IPv6 und warum das Regelwerk anfänglich nicht funktioniert hat.
Sollte das der Fall sein, wäre das ggf. noch mal ein Hinweis für die Verbesserung seines Howtos, denn in die Falle tappen bestimmt viele. Er sollte kurz auf die Policies in seiner Firewall eingehen. Deshalb hat er auch vermutlich dieses unterschiedliche Feedback auf seine Anleitung: Bei einigen gehts sofort, bei anderen nie. Die, bei denen es nie geht, sind die, bei denen die Policy nicht zur Anleitung passt - warum auch immer.
-
Das wurde mir bspw aber auch mal von einem Lancom Mitarbeiter gesagt.
Das die Ubiquiti Firewall generell erstmal alles offen hat. und bei Lancom sei erstmal alles auf deny all, bis man die Dienste jeweils freischaltet?
Was auch immer der LANCOM Kollege damit erreichen wollte. Ich hatte ja extra die Dokumentation verlinkt, aus der hervorgeht, dass die Default Policy "drop" ist.
-
Im Screenshot oben sieht man, dass die UDM-Pro praktisch nichts von außen annimmt. Für ein erfolgreiches "Ping" müssen ICMP Echo Requests von außen zugelassen werden: für "In", wenn Geräte im LAN anpingbar sein sollen, und für "Local", wenn die UDM-Pro anpingbar sein soll. Ansonsten müssen eben die Dienste freigegeben werden,
Tja, siehe Beitrag #2 und #4. Wir hätten uns den ganzen Thread also sparen können, wenn die Hinweise da schon befolgt worden wären.
Wie hast du ihn denn im Chat davon überzeugt, dass er Hand anlegen muss und sein Netz nicht "offen" ist? Mit wollte er es ja nicht glauben.
Ich frag mich auch, was der Kollege aus dem Nachbarforum, der ja "echt fit" ist, so gemacht hat, wenn selbst die grundlegendsten Firewallregeln für den Anwendungsfall nicht da sind.
