Nun ja, ich wuerde da vermutlich einfach mal versuchen die MAC zu clonen bevor ich den Router austausche...
So einfach ist es leider nicht (mehr) einer Fritze eine andere MAC-Adresse (macdsl) zu verpassen. Wäre schön und ich hätte da auch das ein oder andere Mal den Bedarf hierfür gehabt.
Isch 'abe gar kein Auto^W^W keine Fritze... (ich offenbare wohl mein Alter durch diese Werbungsreferenz)
daher stelle ich mir das wohl einfacher vor als es fuer die Mehrheit der Nutzer sein duerfte...
Ein Grund mehr bei OpenWrt Routern zu bleiben 
Evtl. sollte ich präzisieren: FRITZ!OS anstatt Fritze.
Natürlich ist die Einstiegshürde von OpenWrt und MikroTIKs RouterOS deutlich höher. Durch diese niedrigschwellige Eigenschaften des FRITZ!OS sind die Produkte in D so weit verbreitet. Ich traue mir zwar zu, mich in die Vorgenannten einzuarbeiten (Achtung Werbereferenzierung:) ohne gleich in die Luft zu gehen. Ich bin jedoch auch sicher nicht der Standardnutzer und ab einem gewissen Alter ist die Trägheit die prägende Kraft.
Evtl. sollte ich präzisieren: FRITZ!OS anstatt Fritze.
Natürlich ist die Einstiegshürde von OpenWrt und MikroTIKs RouterOS deutlich höher. Durch diese niedrigschwellige Eigenschaften des FRITZ!OS sind die Produkte in D so weit verbreitet. Ich traue mir zwar zu, mich in die Vorgenannten einzuarbeiten (Achtung Werbereferenzierung:) ohne gleich in die Luft zu gehen. Ich bin jedoch auch sicher nicht der Standardnutzer und ab einem gewissen Alter ist die Trägheit die prägende Kraft.
Das sehe ich weitestgehend auch so.
Die AVM-Teile sind für die Nutzung im familiären Umfeld extrem geeignet. Gerade wenn es darum geht, z.B. die Kids im Zaum zu halten, sind sie sehr geschmeidig, aber auch mit der Telefonzentrale lässt sich sehr viel anstellen, weil sie sogar einen eigenen SIP-Server integriert haben (Video-Klingel an Fritz!Fon incl. Bild).
Aber trotz meines Alters bin ich noch ein Spielkind (25 Jahre Netzwerktechnik) und habe Unifi.
So einfach ist es leider nicht (mehr) einer Fritze eine andere MAC-Adresse (macdsl) zu verpassen.
Darf man mal fragen was da ggf. das Problem ist? Ich habe die Funktion zwar in den letzten Jahren nicht mehr genutzt bzw. nicht mehr nutzen müssen bei FRITZ!OS (imo zuletzt bei einer 7272 oder 7490), weiß also nicht ob diese tatsächlich (noch) funktioniert, aber grundsätzlich angeboten wird das Feature (abweichende MAC-Adresse für das WAN-Interface verwenden) zumindest noch im WebGUI:
Allerdings wird diese Funktion im WebGUI tatsächlich nur dann angeboten, wenn man "keine Zugangsdaten" (also kein PPPoE) verwendet (was aber imo schon immer so war). Und es steht ggf. auch nicht bei allen Anbieter-Profilen zur Verfügung. Aber letzteres sollte kein Problem darstellen, da man dazu dann einfach "anderer Anbieter" verwendet (was sich bei der DG auch aus anderen Gründen empfiehlt, damit man den TrafficShaper konfigurieren kann).
Aber vielleicht gibt es ein anderes Problem und das was man dort eingibt wird seitens FRITZ!OS mittlerweile ignoriert?
Des Weiteren gibt es die entspr. Option auch in der ar7.cfg (und könnte dort manuell eingetragen werden, s.h. "enable_mac_override" und "macdsl_override") aber hier scheint es tatsächlich so zu sein, das habe ich zumindest vor ein paar Jahren mit älteren FritzBoxen bzw. FRITZ!OS-Versionen festgestellt, dass das dort ignoriert wird wenn PPPoE verwendet wird (daher auch verständlich, dass das Feature im WebGUI nicht zur Verfügung steht, wenn man PPPoE verwendet).
In den aktuellen OS ist es für DE nicht mehr vorgesehen, die MAC zu klonen.
Wohl der Preis dafuer von vielen ISPs als Mietrouter angeboten zu werden, wuerde ich vermuten... man kann sich das auch schoenreden als "vermeidet Verwirrung bei unbedarften Endkunden"....
Eine kurze Anmerkung: Packetloss im Internet mittels Ping zu untersuchen, ist keine stabile Lösung, da viele Router ICMP entweder nicht oder nur instabil beantworten. Das geht nur, wenn man eine stabile Gegenstelle hat.
Am Einfachsten ist es, am PC Wireshark mitlaufen zu lassen und u.a. mit I/O Graph die TCP-Fehler zu analysieren. Immer im Hinterkopf behalten: Zuerst sucht man hier nach Fehlern. im eigenen Netz: Habe ich ein LAN? Sind Switche vielleicht kaskadiert, habe ich einen Loop gesteckt, etc. Und natürlich: ist vielleicht irgendwo ein LAN-Kabel defekt. Du kannst z.B. mit Iperf3 zwischen Geräten in Deinem Netz nach Störungen suchen.
Eine kurze Anmerkung: Packetloss im Internet mittels Ping zu untersuchen, ist keine stabile Lösung, da viele Router ICMP entweder nicht oder nur instabil beantworten. Das geht nur, wenn man eine stabile Gegenstelle hat.
Stimmt schon, allerdings ist das Fehlerbild hier im Traceroute (nicht nur Ping zum Endhost) schon diagnostisch auswertbar. Wenn es bei allen Hops (oder allen Hops hinter einem Hop N) einen aehnlichen Bodensatz an Paketverlust gibt, dann deutet vie darauf hin, dass dieser Verlust an Hop N (oder am egress von Hop N-1) entsteht. Klar ist kein harter Beweis, aber ein deutliches Indiz.
Wie geschrieben: Die "Hops", also die Router, antworten oft nicht auf ICMP-Anfragen. Das darf man nicht als Paketverlust werten.
Deswegen schaut man nach einer gleichmässigkeit von Verlusten die sich bis zum Ziel hin durchzieht und nicht auf irgendwelche isolierten mittendrin.
Und dann kann es immer noch am eigenen Netzwerk liegen...
In den aktuellen OS ist es für DE nicht mehr vorgesehen, die MAC zu klonen.
Ich glaube du verwechselst das mit der GPON-Seriennummer.
In den aktuellen OS ist es für DE nicht mehr vorgesehen, die MAC zu klonen.
Was genau bedeutet das? Denn auch in den aktuellen FRITZ!OS-Versionen gibt es weiterhin die entspr. Option, eine eigene MAC zu verwenden. Wird diese dann "nur" ignoriert? Ich möchte es halt gerade nicht testen…
Edit:
Ich glaube du verwechselst das mit der GPON-Seriennummer.
Ah ja. Ich befürchte, das wird hier wohl der Fall sein…
Edit #2:
Das hat mir jetzt keine Ruhe gelassen und habe es mit einer 7530 und aktuellem FRITZ!OS Stable-Release (Ver. 164.08.21-127222) getestet, die Funktion eine eigene MAC für den WAN-Port zu verwenden ist nach wie vor gegeben und funktioniert auch:
Und dann kann es immer noch am eigenen Netzwerk liegen...
Danke fuer Deine Kommentare. Ich mach das jetzt schon ein paar Jahre Hobby-maessig und ich meine ich verstehe die Problematik ganz gut und kann auch traceroutes ganz passabel lesen. Wie schon oben erwaehnt ein traceroute ist immer nur ein Indiz, aber in den richtigen Haenden ein relativ starkes Indiz. Damit will ich es gut sein lassen und nur mein Lieblings-Howto zu dem Thema verlinken:
https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf
(von ::1 aus einem anderen Thread)
Ok, dann befindest du dich am "Frankfurt-BNG-Cluster1" der DG. Der deckt die beiden folgenden /41-Blöcke ab:
- 2a00:6020:5000::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:40::/112 (BNG=2a00:6020:ffff:ffff::d)
- 2a00:6020:5080::/41 mit WAN-Port-Adressen aus 2a00:6020:1000:41::/112 (BNG=2a00:6020:ffff:ffff::e)
Aktuell gehen meine Verbindungen über den ffff::e, das konnte ich jetzt herausfinden.
Zahni ich will ja mein Netzwerk ausschließen. Oder als Schuldigen finden. Da aber interne alle Pings (icmp und tcp) 100% ohne Loss sind, und auch die Interfacestatistikten meines Homeservers sowie der OPNSense keinerlei Loss / error / transmit /crc oder sonstige Probleme anzeigen, kann ich das lokale Netzwerk eigentlich schon ausschließen. Hardware der OPNSense habe ich schon drei verschiedene getestet - mit immer dem gleichen Fehlerbild.
Ab dem ONT ist es Blackbox und genau da versuche ich Licht reinzubringen.
Ich kenne mich mit Hardware und Netzwerken schon ein wenig aus, natürlich keine ISP Konstruktionen. Deswegen Danke an ::1 für die Insights.
Ich habe mir aber nochmal die Ripe Rrobes von ::1 angesehen., Wenn man bei den Probes die am Franfurter Knoten hängen, auf einen Monat geht, sieht man auch den Packetloss beim Hovern über die Messpunkte. ICMP hin oder her.
Wenn man das jetzt auf ein Jahr zieht, sieht man optisch (jeder schwarze Kringel ist ein Loss) alleine schon Optisch bereits, das sich da im September (zumindest bei dieser Probe) deutlich was geändert hat. Bei mir ist das Problem Anfang / Mitte November das erste mal aufgetreten.
Und ich spiele seit über 5 Jahren online ein (altes) Multiplayer Online Game, was konstant per TCP arbeitet und man jeden Loss sofort bemerkt. Und vor November 2025 ist mir da nie etwas aufgefallen - das muss man mir halt auch ohne Graphen glauben
Bedeutet wohl für mich, dass ich hier meine Hoffnungen auf saubere Verbindungen erstmal begraben kann. Traurig.
Der hier hängt auch an deinem BNG-Cluster (100.124.1.11, 2a00:6020:ffff:ffff::e):
Die Paketverluste sind hier stark abhängig vom Ziel (die man einzeln sehen kann. wenn man in der Legende auf das jeweilige Ziel klickt:
Aber schau dir mal eine Probe am Anschluss eines anderen Providers an, z.B. den hier (Telekom):
Das sieht auch nicht viel besser aus.
Ich halte die Aussagekraft solcher Messungen für sehr begrenzt.
Auf die Packet Loss Angaben der Atlas Nodes würde ich nicht zu viel geben. Das sieht bei mir so aus:
Und der Packet Loss Test so:
Atlas: Katastrophe. Realität: keinerlei Problem. Die Pakete gehen sonstwo verloren, aber nicht im Einflussbereich meines Anschlusses.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
