IPv6 hakt ständig

    Wie in diesem Forum empfohlen habe ich mir nun ein "routed network" für IPv6 dazu gebucht, damit ich IPv6 ohne NAT nutzen kann.


    In meinem Szenario habe ich dieses geroutete Netz genutzt, um meinen Containern statische IPv6 Adressen zu geben.


    Wie ich festgestellt habe hakt es aber ständig. Ich kann eine IP von außen ca. 30-40s lang anpingen und dann kommt plötzlich eine Sendepause wo die IP auf einmal nicht mehr erreichbar ist.


    Irgendwann geht es plötzlich wieder.


    Ich habe zusätzlich auch noch den ndppd installiert obwohl der für geroutete Netze ja eingentlich nicht notwenig ist. Aber auch das hilft nicht.


    Diese Tipp hier hat mir auch nicht geholfen:


    Zusätzliche IP Adresse konfigurieren – netcup Wiki


    Die IPv6 Adresse des Servers selbst ist immer erreichbar.


    Nur die IPs, die an dem gerouteten Netz hängen sind davon betroffen.


    Ich habe nun folgenden Test gemacht: ich pinge das podman1 Interface meines Servers (das ist eine IP aus dem gerouteten Netz).


    Nun kriege ich wie gesagt etwas 30-40 pings durch und dann bleibt alles stehen.


    Wenn ich aber auf dem Server einen Dauerping auf die IPv6 des Google DNS setze und laufen lasse dann läuft mein ping weiter.


    Das sieht ja nach irgendeinem Timeout Problem aus. Weiß jemand was man da machen kann? Der Dauerping auf Google kann ja wohl nicht die Lösung sein.

  • Zur hilfreichsten Antwort springen

    Der Server hatte ja schon vor der Anschaffung des Zusatznetzes eine IPv6. Diese hat er auch weiterhin. Von default sehe ich da nichts. Es gibt halt die beiden Netze.


    Das neue geroutete Netz habe ich im SCP mit dieser IP verbunden. Das war der Schritt, der nicht ohne den Support wieder rückgängig gemacht werden kann.


    Das geroutete Netz nutze ich auf dem Server für podman.

    Von wo pingst du denn? Kannst du mal mit Hilfe eines Traceroutes herausfinden, wo die Pakete verloren gehen?


    Da das Subnetz ja direkt auf die standardmäßige IPv6 deines Servers geroutet wird, vermute ich stark ein Problem auf deinem Server. Beinhaltet die Firewall Regeln für Pings? Vielleicht mit limit oder burst Optionen?

    Zitat von fansari

    Wenn ich aber auf dem Server einen Dauerping auf die IPv6 des Google DNS setze und laufen lasse dann läuft mein ping weiter.

    Pingst du vom Host oder von einer VM? Sprich: ist die Absenderadresse deine standardmäßige IPv6 oder eine IP aus dem gerouteten Subnetz?


    Ansonsten ist es Zeit, mittels tcpdump Paketmittschnitte zu erzeugen und zu analysieren, wo die Pakete ankommen.

    du hast jetzt 2 IPv6-Netze

    das welches beim Server dabei ist nennen wir es 2a03:4000:1:0::/64

    und das zusätzliche nennen wir es: 2a03:4000:1000:0::/64


    im SCP siehst Du irgendwo sowas


    2a03:4000:1000:0::/64 -> 2a03:4000:1:0:aaaa:bbbb:cccc:dddd


    und genau die IPv6 rechts ist die IPv6-Adresse welche Du deinem Server am eth0, ens3, ... Interface geben musst;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Gefällt mir 2

    Also erstmal wegen der Netze: so wie du das beschrieben hast ist es auch mir. Die IP rechts vom Pfeil ist die IP meines Servers. Die hate er auch schon bevor ich das neue Netz gekauft habe.


    Ich pinge von meinem PC (der wiederum an einer FritzBox hängt) den Server an. Ich habe durch meinen ISP ein /64er IPv6 Netz. Ich pinge also von IPv6 nach IPv6.


    Mit tracepath habe ich jetzt auch versucht.


    In dem Fall wo es nicht mehr geht ist die letzte IP Adresese wo noch Replies kommen diese hier:


    2a03:4000:ff00:1::1


    In dem Fall wo es geht kommt direkt danach dann meine IP, die ich anpinge.


    Daraus folgt, dass die 2a03:4000:ff00:1::1 immer anpingbar sein müsste. Das scheint auch so zu sein.


    Ich kann auch statt Google diese IP anpingen und habe dasselbe Ergebnis.


    Allerdings möchte ich, dass ich auch ohne Dauerpings IPv6 zur Verfügung habe.


    An der Firewall liegt es nicht. Wenn ich nftables abschalte verhält sich alles genau wie vorher.

    Ja, ich hatte ens3 eingetragen und testweise auch noch podman1.


    Wenn ich das hier ausführe:


    sysctl -a | grep 'accept_ra = '


    Dann sehe ich


    net.ipv6.conf.all.accept_ra = 2

    net.ipv6.conf.default.accept_ra = 0

    net.ipv6.conf.ens3.accept_ra = 0

    net.ipv6.conf.lo.accept_ra = 1

    net.ipv6.conf.podman1.accept_ra = 0

    net.ipv6.conf.veth9567d854.accept_ra = 1

    net.ipv6.conf.vetha94122d.accept_ra = 1

    net.ipv6.conf.vethb7c03cd.accept_ra = 1

    net.ipv6.conf.vethc1dfe830.accept_ra = 1

    net.ipv6.conf.vethc70e0a79.accept_ra = 1

    net.ipv6.conf.vetheeef9bc8.accept_ra = 1

    net.ipv6.conf.vethfbe7e734.accept_ra = 1


    Im Test versuche ich ja das podman1 Interface zu pingen. Da steht accep_ra auf 0 wie in deser Anleitung.

    an Hand dem läßt sich vermuten, dass das NIC Interface auf Deinem vServer ens3 ist,


    und befindet sich unter den IPv6-Adressen des ens3-Interfaces eine Scope:Global des vServer-IPv6-Prefixes,

    deren hintere 64-bit ident mit der Scope:Link Adresse fe80::... des vServers ist?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Ja, die global scope IP ist auf ens3.


    Die fe80:: Adresse hat im hinteren Teil nicht die 64 Bit meiner Host IP. Letztere habe ich gemäß SLAAC nach der MAC Adresse aufgebaut. Die Loal-Link Adresse ist dagegen nicht nach SLAAC aufgebaut. Das ist allerdings auf meinem PC genauso. Die wird wohl automatisch vergeben.


    Mag sein, dass es nicht notwendig oder sinnvoll ist accept_ra=2 zu setzen. Ich habe das jetzt auf 0 gesetzt und die VM neu gestartet.


    Nun sieht es foldgendermaßen aus:


    net.ipv6.conf.all.accept_ra = 0

    net.ipv6.conf.default.accept_ra = 0

    net.ipv6.conf.ens3.accept_ra = 0

    net.ipv6.conf.lo.accept_ra = 1

    net.ipv6.conf.podman1.accept_ra = 0

    net.ipv6.conf.veth35ad154e.accept_ra = 0

    net.ipv6.conf.veth3fb3fe66.accept_ra = 0

    net.ipv6.conf.veth4b34798c.accept_ra = 0

    net.ipv6.conf.vetha2e16c4e.accept_ra = 0

    net.ipv6.conf.vetha71fe744.accept_ra = 0

    net.ipv6.conf.vethbe1d18a8.accept_ra = 0

    net.ipv6.conf.vethf912c47.accept_ra = 0


    Allerdings ändert das nichts am Verhalten.


    Ich habe mal getestet die IP vom nicht gerouteten Netz von außen zu pingen (also die IP, die auf ens3 liegt).


    Wenn ich diese IP von meinem PC aus anpinge dann funktioniert der ping auf das geroutete Netz auch wieder (das hatte ich ja gestern schon mit pings von drinnen nach draußen getestet).


    Man kann also sagen: nur wenn Traffic über das nicht geroutete Netz läuft, funktioniert auch das geroutete Netz. Andernfalls friert das geroutete Netz einfach ein.


    So ist das aber nicht gedacht. Das nicht geroutete Netz soll nur dazu verwendet werden, dass der Server per SSH erreichbar ist.


    Das geroutete Netz ist für podman und die Container und soll erreichbar sein auch wenn über das nicht geroutete Netz kein Traffic geht.

    Zitat von fansari

    Die fe80:: Adresse hat im hinteren Teil nicht die 64 Bit meiner Host IP. Letztere habe ich gemäß SLAAC nach der MAC Adresse aufgebaut. Die Loal-Link Adresse ist dagegen nicht nach SLAAC aufgebaut. Das ist allerdings auf meinem PC genauso. Die wird wohl automatisch vergeben.

    Entscheidend ist folgendes: das Ziel für das geroutete Netz ist fest vorgegeben. Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas. Wenn da irgendwas an der Adresse rumfummelt, dann würde das zuverlässig deine Probleme erklären.


    Hast du die Verbindung auch mal anders als per Ping getestet?

    Ja, ich habe die IP auch anders als mit ping getestet. Wie gesagt ich nutze sie für SSH. Bevor ich dieses zusätzliche geroutete Netz hatte war das das einzige Netz.


    ens3: wie gesagt: die fe80::... Adresse hat nichts mit der IPv6 auf dem Interface gemeinsam. Aber genauso ist das auch bei meinem PC, der an einer FritzBox hängt. Ich gehe davon aus, dass das "normal" ist. Das liegt daran, dass addr-gen-mode auf "stable-privacy" eingestellt ist. Meines Wissens nach ist das der Defaultwert.


    Vom Server aus ist sie auch pingbar:


    PING fe80::f429:f8c3:64a:8694%ens3(fe80::f429:f8c3:64a:8694%ens3) 56 data bytes

    64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=1 ttl=64 time=0.078 ms

    64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=2 ttl=64 time=0.101 ms

    64 bytes from fe80::f429:f8c3:64a:8694%ens3: icmp_seq=3 ttl=64 time=0.077 ms


    Aber ich habe nun mal auf ens3 addr-gen-mode=eui64 eingestellt. Nach dem Neustart des Interfaces entspricht die fe80 Adresse damit der nach SLAAC umgerechneten MAC Adresse.


    Wenn das jetzt nicht nur Zufall ist dann würde ich sagen: jetzt laufen die Pings tatsächlich durch! Ich habe mehrfach auf stable-privacy zurückgewechselt um sicher zu gehen, dass es tatsächlich daran liegt. Und damit hakt es wieder.


    Sollte das weiterhin so stabil laufen wäre das Problem für mich gelöst.


    Aber was macht netcup da? Das Thema IPv6 ist hier schon sehr merkwürdig. Zunächst einmal hätte ich erwartet, dass das mitgelieferte IPv6 Netz ausreichend ist und man lediglich einen Proxy NDP (entweder statisch oder halt den ndppd) braucht. Stattdessen muss man ein zusätzliches geroutetes Netz kaufen. Was ist das denn?


    Und jetzt das hier: stable-privacy ist die Default Einstellung für IPv6. Darauf dass man auf eui64 wecheln muss, muss man erstmal kommen. Dass mir nicht klar ist, warum stable-privacy hier "unstable" ist brauche ich wohl nicht extra zu erwähnen.


    Auf jeden Fall danke für eure Unterstüzung.

  • fansari

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.
    Zitat von fansari

    ens3: wie gesagt: die fe80::... Adresse hat nichts mit der IPv6 auf dem Interface gemeinsam.

    aber genau das sollte es ... wurde bereits mehrfach darauf hingewiesen;


    Samstag 18:54

    Zitat von mainziman

    hast Du dem vServer die 'default'-IPv6 gegeben, welche er Dir im SCP anzeigt?

    Samstag 19:28

    Samstag 20:31

    Zitat von mainziman

    und befindet sich unter den IPv6-Adressen des ens3-Interfaces eine Scope:Global des vServer-IPv6-Prefixes,

    deren hintere 64-bit ident mit der Scope:Link Adresse fe80::... des vServers ist?

    Sonntag 18:39

    Zitat von frank_m

    Entscheidend ist folgendes: das Ziel für das geroutete Netz ist fest vorgegeben. Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas. Wenn da irgendwas an der Adresse rumfummelt, dann würde das zuverlässig deine Probleme erklären.


    mach das einfach mal und Deine Probleme sind gelöst ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Zitat von fansari

    Aber was macht netcup da?

    Also wenn man die Default Images von netcup installiert, dann ist die IPv6 auf dem internen Interface genau so gesetzt, wie es erforderlich ist. Wenn das bei dir nicht der Fall war, würde ich eher fragen: Was machst du denn da?


    Zitat von fansari

    Und jetzt das hier: stable-privacy ist die Default Einstellung für IPv6.

    Sorry, nein. Die Default Einstellung auf einem Server ist eine statische IPv6. Da haben stable-privacy oder sonstwelche dynamischen Adresstools absolut gar nichts verloren! Lies dir noch mal meinen Satz von oben durch: "Diese Adresse muss statisch fest auf dem primären Interface eingestellt sein - ohne Schnickschnack, ohne irgendwelche RA Spielereien oder sonstwas."


    Zitat von fansari

    Dass mir nicht klar ist, warum stable-privacy hier "unstable" ist brauche ich wohl nicht extra zu erwähnen.

    Die Frage ist jetzt hoffentlich nicht dein Ernst, oder? Du hast nicht den Hauch einer Ahnung, warum du diese spezifische Adresse brauchst? Wo soll deiner Meinung nach das zusätzliche IPv6 Netz denn hingeroutet werden? Sollen die Router von netcup hellsehen?

    Ich verstehe nicht was du meinst. Was ist ein "Default Image" von netcup? Ich bin zu Netcup gewechselt, um die Linux Distribution installieren zu können, die ich bevorzuge. In meinem Fall ist das Fedora Core OS.


    Natürlich muss mein Interface eine public IPv6 Adresse haben. So ist mein Server ja auch eingerichtet. Ich habe nie etwas anderes behauptet.


    Bei der Diskussion um stable-privacy und eui64 ging es lediglich um die link-local Adresse (also die fe80:...). Diese Adresse wird ja eh nicht geroutet sondern ist nur für die "neigbors" sichtbar.


    Die Router von netcup sollen den Traffic zu meiner statitschen IPv6 Adresse routen (also der 2003:4000:...). So ist es ja auch im Netzwerkbereich vom servicecontrolpanel eingerichtet.


    Mein Problem wurde nun dadurch gelöst, dass die link-local Adresse statt stable-privacy nun eui64 ist. Das hat ja nichts mit der statischen public IP zu tun.


    Was mir noch unklar ist, ist warum es mitt der link-local Adresse nach eui64 funktioniert und nach stable-privacy nicht.


    Da ich meine statische IPv6 Adresse nach SLAAC aufgebaut (also gemäß der MAC Adresse) frage ich mich auch: was genau hat das Problem nun gelöst? Dass die link-local IP vom Schema her mit der public IP übereinstimmt? Oder dass die link-local nun zu der MAC Adresse passt?


    Um das testen zu können müsste ich meine public IP ändern. Das könnte ich zwar machen - allerdings ist die Zuordnung von dieser Adresse zu der Adresse des gerouteten Netzwerks nur über den Support zu ändern.


    Da es so wie es jetzt ist funktioniert werde ich das allerdings nicht machen.


    Fazit: bei stimmen jetzt public IP, link-local Adresse und MAC überein (nach SLAAC) und damit funzt es nun.

    Er meinst wahrscheinlich damit, dass du das Image von Netcup verwendetes und keins selber bei FTP hochgeladen hast.

    Zitat von fansari

    Ich verstehe nicht was du meinst. Was ist ein "Default Image" von netcup?

    Ich meine die Installationsimages von netcup. Wenn du da eigene Wege gehst, musst du natürlich selber dafür sorgen, dass alle Voraussetzungen für einen stabilen Betrieb gegeben sind. Daran ist es offensichtlich gescheitert.

    Zitat von fansari

    Natürlich muss mein Interface eine public IPv6 Adresse haben. So ist mein Server ja auch eingerichtet.

    Nein, er muss nicht eine, sondern eine ganz spezielle public IPv6 haben. Das ist der entscheidende Punkt. Es muss exakt die aus dem SCP sein, die als Routing Endpoint für das zusätzliche IPv6 angegeben ist. Die ist auch nicht änderbar, die ist seitens netcup fest vorgegeben, und es ist die mit deinem IPv6 Prefix und der EUI64 Host ID deines Servers.

    Zitat von fansari

    Bei der Diskussion um stable-privacy und eui64 ging es lediglich um die link-local Adresse (also die fe80:...).

    Nein, geht es nicht. Es geht um die öffentliche IP. Die link-lokale ist in diesem Zusammenhang völlig egal. Damit die link-lokale Adresse nicht mit EUI64 gebildet wird, müssen Kernel oder sysctl Parameter geändert werden. Mir wäre keine Distribution bekannt, wo das standardmäßig gesetzt wird. Ist aber in diesem Fall auch völlig egal.

    Zitat von fansari

    Diese Adresse wird ja eh nicht geroutet sondern ist nur für die "neigbors" sichtbar.

    Eben. Es macht doch gar keinen Sinn, für eine link-lokale Adresse irgendwelche Privacy Extensions zu aktivieren, da Pakete mit dieser Adresse das lokale Netz ja nie verlassen - und im lokalen Netz ist die MAC ja eh bekannt.

    Zitat von fansari

    Die Router von netcup sollen den Traffic zu meiner statitschen IPv6 Adresse routen (also der 2003:4000:...). So ist es ja auch im Netzwerkbereich vom servicecontrolpanel eingerichtet.

    Eben. Diese Einstellungen im networkmanager (oder wo auch immer) beziehen sich auf jeden Fall auch auf die öffentliche IP, die dem Interface zugewiesen wird. Schau dir einfach die öffentliche IP auf deinem Interface an, wenn du die Einstellung veränderst. Und dann vergleiche sie mit dem Routing-Ziel für das zusätzliche IPv6 Netz im SCP, das du selber hier erwähnst. Klingelts jetzt?

    Zitat von fansari

    Mein Problem wurde nun dadurch gelöst, dass die link-local Adresse statt stable-privacy nun eui64 ist. Das hat ja nichts mit der statischen public IP zu tun.

    Erkennst du nun den Widerspruch dieser Aussage, wenn du es mit deinen obigen Aussagen vergleichst? Du schreibst selber, dass das Routing Ziel die öffentliche Adresse ist, und dann soll eine Änderung der link-lokalen Adresse eine Änderung bringen?

    Zitat von fansari

    Da ich meine statische IPv6 Adresse nach SLAAC aufgebaut (also gemäß der MAC Adresse) frage ich mich auch: was genau hat das Problem nun gelöst?

    Der Satz ist ja auch schon ein Widerspruch in sich. SLAAC ist ein Mechanismus für dynamische Adressen, nicht für statische. Den einzigen Einfluss, den du auf deine statische Adresse haben kannst, ist die Host-ID. Die kannst du selber festlegen, aber die ist fest vorgegeben für das Routing Ziel, nämlich eine Host-ID nach EUI64.


    Wenn du mich fragst, ist Folgendes passiert: Du hast wahrscheinlich irgendwo eine statische IPv6 gesetzt, aber gleichzeitig im networkmanager oder sonstwo die Einstellung "stable-privacy" aktiv gehabt. Damit hattest du eine dymaische öffentliche IP auf dem Interface, die nicht zum Routing Ziel des IPv6 Netzes passte.

    Nun hast du die stable-privacy Einstellung geändert, deine dynamische Adresse ist nun zufällig identisch mit der statischen Adresse, und das Routing Ziel bleibt stabil. Die link-lokale Adresse hat damit gar nichts zu tun, und ich wage auch zu bezweifeln, dass sie sich überhaupt geändert hat.


    Ich an deiner Stelle würde die gesamte dynamischen Adresstools deaktivieren. Server leben davon, dass sie statische Adressen haben, damit sich das Ziel von Nameserver-Einträgen und Routing Regeln nicht plötzlich ändert. Da haben solche Tools einfach nichts verloren.

    Ob deine Vermutungen stimmen lässt sich ja leicht testen.


    Ich gehe also wieder zurück auf stable-privacy und siehe da der ping bleibt wieder stehen.


    Nun schaue ich mir ens3 an. Ist dort nun eine andere oder zusätzliche IP? Nein, wie gehabt. Nur eine statische IP und zwar genau die, die da vorher auch war.


    Und wie sieht nun die fe80 Adresse aus? Nun ist es irgendeine gewürftelte IP, die nicht mehr zur MAC Addresse passt.


    Nun wieder Rolle rückwärts auf eui64: der ping läuft wieder durch und die fe80 Adresse passt wieder zur MAC Adresse und sonst ist alles gleich.


    Es liegt also eindeutig an der fe80 Adresse. Auch die anderen Parameter (scope global noprefixroute bzw. scope link noprefixroute) sind gleich geblieben.