Beiträge von CrazyFiber

Kurzes Update: Meinen Workaround konnte ich mittlerweile wieder entfernen weil die Stadtwerke das Problem gelöst hat.

Es war tatsächlich ein fehlkonfiguriertes Gerät im Netzwerk welches nun keine RA's mehr sendet.

Zitat von frank_m

Ist denn sichergestellt, dass der überhaupt da ist, wenn die Fritzbox angeschlossen ist? Hast du das mal anhand eines Paketmitschnitts überprüft?

Jop, der ist dann auch da.

Ich habe das Problem bei mir erstmal temporär behoben in dem ich die IPv6 des Cisco Routers für RA's in der Firewall der UDMP geblockt habe. Seit dem funktioniert alles wie es soll.

Ich zitiere mal die Antwort des Supports:

Zitat

In the non-working setup, the UDM-Pro is continuously logging:

Code

Apr 11 23:38:56 ubnt user.warn ubios-udapi-server: netlink: Multipath routes not supported, got 2 nexthops for route ::/0 via fe80::9ee3:74ff:fef5:e2a7 dev eth9.7

In the working setup, the default gateway is through fe80::9ee3:74ff:fef5:e2a7:

Code

default via fe80::9ee3:74ff:fef5:e2a7 dev eth9.7 table 201 proto ra metric 512 pref medium

Whereas in the non-working setup, the default gateway is through fe80::f2f7:55ff:fe77:4a03:

Code

default via fe80::f2f7:55ff:fe77:4a03 dev eth9.7 table 201 proto ra metric 512 mtu 1500 pref medium

There are multiple routers (one Cisco and one Huawei) connected upstream that are advertising RAs, this leads to the UDM installing a new default gateway (due to a higher router preference) and IPv6 connectivity is lost.

Code

fe80::9ee3:74ff:fef5:e2a7 dev eth9.7 lladdr 9c:e3:74:f5:e2:a7 router REACHABLE
fe80::f2f7:55ff:fe77:4a03 dev eth9.7 lladdr f0:f7:55:77:4a:03 router REACHABLE

There should only be a single next-hop link-local IPv6 address advertised as the default gateway to the UDM-Pro.

Alles anzeigen

Interessant, dass die Fritzbox kein Problem damit hat.

Habe das mal an meinen ISP geschickt, mal schauen ob die damit etwas anfangen können.

frank_m

Leider ist die UDMP UI was IPv6 angeht recht spartanisch... man kann noch nicht einmal irgendwo IPv6 IP's sehen.

Wenn ich wüsste wie ich z.B. die Ping requests über SSH verfolgen könnte hätte ich es gemacht.

Wenn da einer Input oder eine gute Quelle nennt gerne her damit.

frank_m

Aktuell verteilt die UDMP ein /64er Subnetz pro VLAN (lässt sich aktuell auch nicht ändern, passt aber mit meinem /60er Präfix).

Dle Clients erhalten eine IP aus dem Präfix. Die kann auch nach außen telefonieren solange die UDMP nach außen pingen kann und von außen pingbar ist.

Zu deinen anderen Fragen kann ich leider nichts produktives beitragen da meine Linux Kenntnisse auch nur begrenzt sind.

Alle "Schutzmechnismen" die man über die UI abschalten kann habe ich testweise abgeschaltet. Das Verhalten bleibt aber gleich.

Bin bei dem Thema leider noch nicht weiter gekommen.

Bin beim Unifi Support aber mittlereile beim "Tier2" Team angekommen. Mal schauen ob die eine Idee haben.

Mit den neusten EA Versionen ist der Verhalten leider auch immernoch gleich.

In den Supportlogs konnte ich mittlerweile auch sehen, dass das zuweisen der /60 IPv6 funktioniert.

ip route, ip -6 route sowie ip6tables bleiben unverändert.

frank_m

Ich denke dein Ansatz erstmal zu schauen ob die UDMP selber mit IPv6 klar kommt war der richtige.

Ich kann mittlerweile folgendes reproduzieren:

Wenn ich die UDMP reboote oder die Internetverbindung neuaufbaue funktionert IPv6 auf der UDM Pro:

Ich kann von der UDMP per IPv6 rauspingen, die UDMP ist von außen auch pingbar.

Die Clients haben dann auf ipv6-test,com evenfalls eine IPv6 mit 20/20 Punkten.

Nach einiger Zeit (10-30 Sekunden ca.) fällt IPv6 dann aus. Pings (per SSH direkt von der UDMP) gehen nicht mehr raus und kommen auch nicht mehr rein (sind aber wir oben erwähnt im TCP dump noch zu sehen).

Per "ip addr" und "ifconfig" kann ich keine relevante Änderung feststellen.

Unter ifconfig sehe ich unter eth9.7 (Sollte der SFP Port, VLAN 7 sein):

eth9.7    Link encap:Ethernet  HWaddr E0:63:DA:xx:xx:xx
          inet addr:100.64.xx.xxx  Bcast:0.0.0.0  Mask:255.255.240.0
          inet6 addr: fe80::e263:daff:fe5a:f032/64 Scope:Link
          inet6 addr: 2a04:xxxx:xxx:1000::1:xxxx/128 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18558697 errors:0 dropped:95329 overruns:0 frame:0
          TX packets:12963376 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29563026231 (27.5 GiB)  TX bytes:3814474800 (3.5 GiB)

Die IPv6 die dort steht ist zwar von außerhalb nicht pingbar (obwohl in der Firewall freigebeben) aber wenn ich einen TCPdump auf eth9 laufen lasse kann ich die ankommenden ICMP6 echo requests sehen. Sie kommen also an.

Von der SSH Console kann ich aber z.B. keine IPv6 Adresse pingen/tracen. Ein nslookup funktionert aber:

# nslookup ipv6.google.com
Server:         127.0.0.1
Address:        127.0.0.1:53

Non-authoritative answer:
ipv6.google.com canonical name = ipv6.l.google.com

Non-authoritative answer:
ipv6.google.com canonical name = ipv6.l.google.com
Name:   ipv6.l.google.com
Address: 2a00:1450:4001:812::200e

PING ipv6.google.com (2a00:1450:4001:830::200e): 56 data bytes

--- ipv6.google.com ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
#



# traceroute -6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4001:812::200e), 30 hops max, 72 byte packets
 1  dynamicIPv6-2a04-xxx--1.isp.ropa.net (2a04:xxx)  3054.329 ms !H  3050.057 ms !H  3071.862 ms !H

frank_m

Ich erhalte eine IPv4 im 100er Bereich (CGNAT wenn ich das richtig zuordne).

Die public IPv4 ist eine 185er und von außen nicht erreichbar (ich habe aber eine dynamische, öffentliche IPv4 dazubestellt die bald eigerichtet werden sollte).

Zur IPv6 finde ich nichts in der Oberfläche. Per SSH sehe ich eine /128 IPv6. Dazu kann ich mehr posten wenn ich später zuhause bin.

Falls du da aber ein paar Infos hast wie ich an relevante Daten kommen kann wäre ich dankbar dafür.

Hallo zusammen,

ich habe einen AON Glasfaseranschluss bei der Stadtwerke Unna.

Wenn ich an meinem ONT die Provider Fritzbox anschließe funktioniert die IPv6 ohne Probleme.

Die Einstellungen in der Fritzbox:

Native IPv4-Anbindung verwenden

DHCPv6 Rapid Commit verwenden

Die automatische IPv6 Präfixlänge ist /60

ipv6-test,com meldet dann:

IPv6: Supported

Type: Native IPv6

SLAAC: No

ICMP: Filtered

Wenn ich das ONT an den WAN Port der UDM Pro anschließe (oder alternativ direkt ein SFP Modul nutz und wie folgt eine Verbindung aufbaue:

VLAN ID: 7

IPv4 Connection: DHCPv4

IPv6 Connection: DHCPv6

Prefix Delegation Size: 60

In meinem Default Netzwerk habe ich folgende Einstellungen:

IPv6 Interface Type: Prefix Delegation

RA: Enabled

RA Prio: High

DHCPv6 Range:Start: ::2

DHCPv6 Range:Stop: ::7d1

DHCPv6/RDNSS DNS Control: Auto

Die IPv4 Verbindung funktioniert ohne Probleme.

ipv6-test,com meldet:

IPv6: Not supported

Kann mir jemand auf die Sprünge helfen?

Ich habe es auch schon mit anderen Prefix längen ausprobiert. Teilweise erhalte ich kurz nach dem Reconnect kurzfirist eine IPv6. Ein ein paar Sekunden/Minuten ist diese dann aber wieder verschwunden.

Danke und Grüße

Crazy

Der kleinste Tarif sind vermutlich 100 Mbit/s = 0,1 Gbit/s.

Deine CAT Kabel sollten also vorerst ausreichen.

Mit dem 50er Vertrag würde der Upload fast halbiert (vermutlich sogar mehr als halbiert). Das kommt für mich leider nicht in Frage.

ich würde auch davon ausgehen, dass wir beim 50er Vertrag nicht die volle Leistung bekommen. Laut Produktinformationsblatt des 100er Tarfis sollten im Download mindestens 54 Mbit bei mir ankommen.. da es 56-57 sind, hatte ich damals schon den leisen Verdacht, dass das kein Zufall ist.

Wenn ich aktuell einen Verfügbarkeitscheck für meine Adresse (inkl anderen Häusern in meiner Straße) mache kann ich auch garkeinen Tarif mehr auswählen. Ich vermute, dass die da am Limit laufen.

Dann muss es wohl leider erstmal so bleiben wie es ist. Danke für die Infos.

ich werde das Thema erst weiter verfolgen, wenn wir einen konkreten Schalttermin für unseren FTTH Anschluss bekommen.

Hallo zusammen,

kurzer Background:

Wir haben einen Helinet VDSL 100/40 Tarif der ursprünglich auch über 90 Mbit/s im Download geschafft hat. Nach einem Internetausfall 2020 kommen allerdings nur noch ca. 56/17 Mbit/s bei uns an (in den Fritzbox Logs sieht man, dass die Box es bei Neuverbindung erst mit 100/40 versucht, dabei die Verbindung verliert und dann mit 56/17 weitermacht).

Wir hatten zwischenzeitlich verschiedene Telekomtechniker hier die das Problem nachvollziehen können aber alle verschiedene Ursachen dokumentiert haben:

- Leitung beschädigt, Bautrupp muss raus (wir haben leider keine Ersatzleitung)

- am Verteilerkasten stimmt etwas nicht

- die Leitungen sind zu alt, dass kann noch nicht geklappt haben

Unterm Strich hat Helinet nichts gemacht und uns angeboten auf einen 50/10 Vertrag downzugraden was wir allerdings dankend abgelehnt haben.

Durch die TKG-Novelle beträgt die restliche Mindestvertragslaufzeit für den Vertrag nur noch einen Monat. Da unser FTTH Anschluss der Stadtwerke aber noch auf sich warten lässt würde ich durch Nachweis über die Breitbandmessung zumindest den Preis mindern wollen.

Da wir hier im Dorf allerdings auf Helinet angewiesen sind (alle anderen Provider bieten max 16 Mbii/s an), habe ich Bedenken, dass Helinet uns den Vertrag kündigt weil sie keine Lust auf solche Spielchen haben.

In den AGB's konnte ich zwar keine Klausel erkennen die der Helinet einen Kündigunsanspruch ohne wichtigen Grund ermöglich würde aber vielleicht hat der Provider ja doch (eventuell im Zusammenhang mit der Vertragslaufzeit von nur noch einem Monat) doch noch einen Hebel in der Hand?!

Hat jemand Erfahrung mit dem Thema und kann etwas dazu sagen?

Danke und Grüße

Crazy'nochnicht'Fiber

Hallo zusammen,

da die Infos auf der Website der Stadtwerke Unna noch recht spärlich sind (keine Schnittstellenbeschreibung etc.), aktuell aber fleißig ausgebaut wird, will ich hier schonmal meine zusammengetragenen Informationen sammeln.

Sobald mein Anschluss steht (vermutlich in Q1 2022) folgt dann noch ein konkretes HowTo mit SFP Modul und UDM-Pro.

Die Stadtwerke Unna bietet seit diesem Jahr einen eigenen Glasfaser Tarif namens glaspower an.

- Anschlussart: AON

- der HÜP kann max. 2 Meter hinter der der Hauseinführung montiert werden

- am HÜP kann ein vom Kunden verlegtes Singlemode OS2 LWL Kabel gespleißt werden

- alternativ kann am HÜP ein LC APC Stecker verwendet werden

- der optionale aktive ONT wird per SC APC angeschlossen

Bei einem eigenen SFP Modul muss folgendes beachtet werden:

Für die Tarife 250/500/750 wird ein 1000BASE-BX10 BIDI Modul benötigt welches mit 1490nm empängt (RX) und mit 1310nm sendet (TX).

Für den 1000er Tarif wird ein 10GBASE-BX10 BIDI SFP+ Modul benötigt. Die Wellenlängen sind mir allerdings unbekannt.

Bei Fragen hat die Stadtwerke kompetente Techniker mit welchen man auch direkt kommunizieren kann.

Alle Angaben ohne Gewähr.

Vielen Dank für die Info!

Hallo zusammen,

wir bekommen demnächst einen Glasfaser Anschluss unserer lokalen Stadtwerke.

Die Stadtwerke bietet an ein bis zum HÜP verlegtes LWL Kabel entweder direkt an den HÜP zu spleißen oder alternativ eine LC/APC Steckverbindng am HÜP zu installieren.

Vom Gefühl her würde ich die Steckverbindung präferieren damit ich das Kabel bei Bedarf austauschen kann. Macht das einen spürbaren Unterschied aus?

Da ich das Kabel über einen SFP+ Transciever direkt an meinen Unifi Router anschließen möchte würde ich dann ein entsprechendes LWL Kabel mit LC/APC (HÜP) und LC/PC (SFP+) Stecker verwenden (ca. 10-15 Meter länge).

Grüße

CrazyFiber