IPv6 Paketverlust bei LXC und mitgeliefertem /64 Subnetz

  • Hey netcup-Forum!


    Ich habe mir vor kurzem LXC (nicht LXD!) auf Debian 10 eingerichtet und wollte nun neben dem IPv4 NAT (lxc-net) jedem Container eine eigene IPv6-Adresse aus dem "mitgeliefertem" /64 Subnetz zuweisen. Das ganze habe ich gelöst mit ndppd, da ich nach ausgiebigem durchforsten des netcup-Forums mehrfach gelesen habe, dass die inkludierten IPv6 Subnetze nicht geroutet sind und deshalb entweder ein zusätzliches IPv6 Subnetz oder ein Neighbor Discovery Proxy die Lösung sei (dazu später mehr). Das ganze hat auch geklappt, nach etwas rumprobieren und troubleshooting mit tcpdump habe ich schließlich eine IPv6-Adresse einem Container zuweisen können. Das Problem ist jedoch, dass beim anpingen des Containers von außen anfangs sehr viele Pakete verloren gehen (manche kommen jedoch vereinzelnt durch) und dann erst nach ca. 70 - 100 Paketen eine stabile Verbindung aufgebaut wird. Bricht man das pingen ab und versucht es nach nur ein paar Sekunden erneut, scheint die Route bereits aus dem Cache gelöscht wurden zu sein und das ganze geht von vorne los.

    Hier mal ein Dump vom Ping:

    Lustigerweise dauert es immer ca. 70 bis 100 Pakete, bis es dann stabil läuft. Pingt man den Container vom Host selbst läuft alles ohne Paketverlust.

    Um euch mal ein paar Infos über mein System zu liefern, hier die Konfiguration vom Host. Jedoch noch vorweg: Da für mich IPv6 und Neighbor Discovery noch recht neu ist und ich mich erst die letzte Woche in die Thematik eingearbeitet habe, weist mich gerne auf mögliche Denkfehler hin!

    Es folgt die Konfiguration vom ipv6test-Container:

    EDIT: Achso, by the way, ::1 ist der Host und ::2 der Container, der restliche Prefix ist der Gleiche.

    Nun noch einmal zum Thema /64 Subnetze: Ich habe leider noch nicht ganz verstanden in wie fern sich die inkludierten Subnetze von den zusätzlichen Subnetzen unterscheiden. Wenn nur die zusätzlichen Subnetze geroutet werden, wie werden dann die mitgelieferten Subnetze aufgeschaltet? Was ist der Grund, weshalb netcup diese unterschiedlich aufschaltet? Und vor allem, wenn der Fehler nicht bei mir liegt (was ich zwar stark hoffe, aber auf Grund von den zahlreichen anderen Threads bezüglich der mitgelieferten /64 Subnetze hier im Forum nicht glaube), was soll ich dann mit 18446744073709551616 IPv6-Adressen die man nicht ordentlich routen kann?

    Ich hoffe mich kann jemand aufklären.


    Vielen Dank schon mal im Voraus! Ich wünsche euch allen ein schönes Wochenende :)!

  • der beim vServer mitgelieferte /64-Prefix ist schon geroutet;

    auch das zusätzliche /64-Prefix ist geroutet;

    wie aber der Pfad weitergeht, sprich zu Deinem Container muss Dein vServer klarerweise veranstalten;


    und die Firewall sollte hier auch etwas weniger rigoros damit umgehen;

    z.B. Prefix::1 ist dein vServer, und Prefix::10:1 Dein Container.

    dann darf die Firewall Deines vServers Zugriffe auf Prefix::10:1 klarerweise nicht blockieren, sondern muss diese weiterrouten ...

    Hinweis: FORWARD bei IP6tables

    Grüße / Greetings

    Walter H.


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

  • Danke für die Antwort!


    Zitat

    der beim vServer mitgelieferte /64-Prefix ist schon geroutet;

    Verstehe ich es richtig, dass ein Neighbor Discovery Proxy dann gar nicht nötig ist? Oder habe ich da etwas falsch verstanden? Ich bin darüber nämlich immer wieder gestoßen, als ich mich hier durch's Forum gelesen habe :).


    Zitat

    Hinweis: FORWARD bei IP6tables

    Oh, das habe ich vergessen: Ich nutze ufw, Forwarding habe ich erlaubt.



    EDIT:
    Ein weiterer Blick auf tcpdump zeigt, dass sogar alle ICMP6 Pakete beim Container ankommen und sogar beantwortet werden. Es kommen aber nicht alle wieder raus...

  • richtig Du brauchst keinen NDP-Proxy;

    sprechen wir von einem zusätzlichen /64-Prefix, od. dem welcher beim vServer mit dabei ist?

    Grüße / Greetings

    Walter H.


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

  • Bei meinen letzten Setups hier bei netcup war ein ndppd notwendig, da die Netze zu dem Zeitpunkt eben *nicht* gerouted waren.


    Versuchs in deiner ndppd.conf mal mit:

    Code
    rule 2a03:4000:2:XXXX:c0de::2/128 {
                    static
            }

    statt iface br0, nach meiner Erfahrung funktionieren weder auto noch iface direktiven beim ndppd.


    Meine config sah damals so aus und damit ließ sich ein inkludiertes /64 problemlos auch hinter einem VPN Tunnel nutzen:

  • Bei meinen letzten Setups hier bei netcup war ein ndppd notwendig, da die Netze zu dem Zeitpunkt eben *nicht* gerouted waren.

    Also ich glaube, hier geht in der Bezeichnung was durcheinander.


    Geroutet werden die Subnetze auf jeden Fall, zumindest bis in die Infrastruktur unmittelbar "vor" dem zuständigen Host. Andernfalls wäre meines Erachtens gar keine Kommunikation möglich, auch schon nicht mit der "Standard-IP".


    Bleibt die Nutzung von ndppd. Die Infrastruktur von netcup muss ja letzlich wissen, wohin sie ein spezifisches Paket zustellen muss. Also schickt sie ein "neighbor solicitation, who has [...]" raus, und zwar als Multicast. Das muss natürlich zunächst mal vom Host mit der gesuchten IP beantwortet werden.


    Multicasts werden üblicherweise nicht weitergeroutet, also z.B. von einem Host in seine virtuellen Maschinen. Folglich wissen die virtuellen Maschinen auch nicht, dass sie gesucht werden und antworten nicht. Hier kommt der ndppd ins Spiel, der die Antworten in Vertretung für die VMs übernimmt. Anschließend landen die Pakete auf dem Host und können an die VMs weitergeroutet werden.


    Meines Erachtens gibt es zwei Alternativen zu ndppd: Ein Multicast Router, der die neighbor solicitations durchleitet, oder eine transparente Bridge, in der alle Netzwerkinterfaces des Hosts und der VMs zusammengeschaltet werden, die auch L2 uneingeschränkt durchlässt. Letzteres ist nicht gut falls man nur eine öffentliche IPv4 hat. Firewall in den VMs ist ein weiterer Aspekt.


    Ich habs gerade mal auf meiner VM getestet und von außen einen Ping auf eine Adresse aus meinem /64 Netz abgesetzt. Wie erwartet kamen direkt die neighbor solicitations für diese IP. Ich hab sie dann mal temporär einem dummy Netzwerkdevice zugeteilt, und sofort wurden die Pings auch beantwortet.

  • Ich habs gerade mal auf meiner VM getestet und von außen einen Ping auf eine Adresse aus meinem /64 Netz abgesetzt. Wie erwartet kamen direkt die neighbor solicitations für diese IP. Ich hab sie dann mal temporär einem dummy Netzwerkdevice zugeteilt, und sofort wurden die Pings auch beantwortet.

    Das

    Das klingt nicht so, als sollte das so sein. Werden die zugewiesenen IP(v4 u v6) Adressen nicht auf die MAC Adressen der jeweiligen VM Interfaces limitiert?

  • Danke schon mal für eure Antworten!


    im Container drinnen kannst Du die IPv6 des fe80:xxx Gateways pingen?

    Ja, das geht (als Gateway im Container nutze ich nicht fe80::1, sondern die Link Local Adresse das Hosts).


    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


    Wie oben schon diskutiert scheint ein Neighbor Discovery Proxy definitiv notwendig zu sein.

    Gute Nachrichten: Das Problem scheint jetzt behoben zu sein. Woran es genau lag kann ich leider noch nicht sagen, ich habe jedoch eine Vermutung. Sobald ich es genau eingrenzen kann, werde ich diesen Post nochmal editieren!
    Ich habe den Host mal neugestartet (was ich jedoch gestern öfters gemacht habe und eigentlich nichts geändert hat) und IPv6 im Container für das Interface deaktiviert, welches an das lxc-net NAT angeschlossen ist.

  • Das klingt nicht so, als sollte das so sein. Werden die zugewiesenen IP(v4 u v6) Adressen nicht auf die MAC Adressen der jeweiligen VM Interfaces limitiert?

    Ja, du hast recht, die Beschreibung war unpräzise. Die IP war als weitere IP auf eth0 angelegt. Auf einem dediziert angelegten dummy Device funktioniert es nicht ohne weiteres.

  • evtl. ein Tipp: verwende vom IPv6/64-Prefix die default Adresse am Host selbst;

    das eth0 Device hat eine fe80::... Adresse und genau des hinter dem fe80::

    verwendest mit dem Prefix, dann sieht die Welt denk ich schon mal ganz anders aus;

    Grüße / Greetings

    Walter H.


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

  • Uff, hier liegt einiges im Argen.


    Erstmal vorweg:

    Das mitgelieferte Netz verhält sich anders als ein zusätzlich gebuchtes Netz.

    Für das mitgelieferte Netz brauchst du einen ND-Proxy - für das zusätzliche Netz nicht.

    Deswegen bezeichnen wir hier im Forum das zusätzliche Netz umgangssprachlich als "geroutet", während das andere Netz nur bedingt geroutet ist ( mainziman ;) )


    Was mir nicht so gut gefällt, ist, dass du eine Bridge hast, die deine NIC beinhaltet und in den Container reinbridged.

    Code
    auto br0
    iface br0 inet static
            address 46.38.XXX.XX
            netmask 21
            gateway 46.38.XXX.1
            bridge_ports ens3

    Ich persönlich würde das nicht so machen. Das kann zu Problemen führen, muss es aber nicht. Den Container würde ich in die lxcbr0 einhängen und ein geroutetes Setup fahren.


    Zur NDPPD Config:


    Hier würde ich die Einstellungen router yes, keepalive yes, und static benutzen.

    Weil das aber alles ein Krampf ist, habe ich mir ein zusätzliches Netz gemietet.

  • So, ich musste mich die letzten Tage nochmal etwas mehr mit der Thematik beschäftigen und wollte nochmal ein Statusupdate geben.


    Was mir nicht so gut gefällt, ist, dass du eine Bridge hast, die deine NIC beinhaltet und in den Container reinbridged.


    [...]

    Ich persönlich würde das nicht so machen. Das kann zu Problemen führen, muss es aber nicht. Den Container würde ich in die lxcbr0 einhängen und ein geroutetes Setup fahren.

    Du hattest auf jeden Fall Recht. Meine vorheriger Lösungsansatz mit der Bridge hat zwar "funktioniert", hat aber tatsächlich zu Problemen geführt und war verhältnismäßig auch viel zu umständlich.

    Ich habe es jetzt, wie von @H6G empfohlen, mit Routing gelöst (ich hoffe jedenfalls dass ich es richtig verstanden habe :D).

    Die Bridge habe ich komplett verworfen, meine /etc/network/interfaces auf dem Host sieht nun wie folgt aus:

    Hier weise ich also nach dem raisen des ens3-Interfaces der lxcbr0 Bridge ein /80 Subnetz hinzu (mir ist leider aufgefallen, dass nach dem Reboot die lxcbr0 Bridge nicht immer bereit zu seien scheint und die Adresse nicht zugewiesen wird, hier scheint es also noch Verbesserungspotential zu geben).

    Im Container weise ich lediglich nur noch die statische IPv6 Adresse zu:

    Als Gateway nutze ich die Public-Adresse die ich der lxcbr0 Bridge zugewiesen habe. fe80::1 funktioniert hier leider (noch) nicht.

    Die ndppd.conf habe ich auch nochmal angepasst:

    Hier proxie ich nun zusätzlich mittlerweile das gesamte /80 Subnetz anstatt einzelner Adressen.

    Nun funktioniert auch alles und ich habe kaum mehr Paketverlust, lediglich zu Anfang wenn die Route wieder aufgebaut wird. Dies Problem bleibt auch weiterhin bestehen (ich nehme mal an jedoch nur mit dem inkludierten /64 Subnetz). Damit die Route im Cache bleibt lege ich in jedem Container einen Cronjob an, welcher alle 3 Minuten mal ein ping -6 -w 60 -c 8 netcup.de macht. Zwar nicht hübsch, funktioniert aber (soweit).

    Falls euch noch irgendetwas auffällt oder ihr Verbesserungsvorschläge habt: Bitte immer her damit! Für mich war dieser kleine Ausflug ins Thema IPv6 mit LXC und manuelle Netzwerk-Konfiguration komplett neu, also falls ich etwas übersehen habe oder man etwas noch eleganter lösen könnte, lasst es mich wissen!

    Schönen Abend wünsch ich euch Allen!

  • Als Gateway nutze ich die Public-Adresse die ich der lxcbr0 Bridge zugewiesen habe. fe80::1 funktioniert hier leider (noch) nicht.

    Auf dem Host: ip -6 addr add fe80::1 dev lxcbr0 - dann kannst du im Container auch fe80::1 als Gateway eintragen.


    Für die initiale Verzögerung hatte ich bisher auch keine Lösung gefunden. Der Ping ist aber ein guter Workaround.

  • Du hast jetzt auf ens3 eine Adresse aus deinem Subnetz mit /64 eingerichtet und auf lxcbr0 mit /80. Zwei Interfaces mit Adressen aus dem gleichen Subnetz. Macht das nicht Schwierigkeiten?

    Sehr gut möglich... Meine Konfiguration ist wie gesagt eine gesunde Mischung aus Trial & Error und Inspiration aus diesem Thread bzw. diesem Blog-Post. Dort scheint alles an das primäre eth0-Interface angebunden zu sein. Dort wird aber auch Ubuntu, netplan und LXD verwendet...

    Auf dem Host: ip -6 addr add fe80::1 dev lxcbr0 - dann kannst du im Container auch fe80::1 als Gateway eintragen.

    Sauber! Hat funktioniert.


    Für die initiale Verzögerung hatte ich bisher auch keine Lösung gefunden. Der Ping ist aber ein guter Workaround.

    Sobald es mal wieder ein /64 Subnetz im Angebot geben sollte werde ich da definitiv zuschlagen! Solang muss der Workaround hinhalten 8o.


    __________________________________________________________________________________________________________________


    Ich muss mich außerdem nochmal korrigieren:

    Zitat von Ich selber

    Hier weise ich also nach dem raisen des ens3-Interfaces der lxcbr0 Bridge ein /80 Subnetz hinzu (mir ist leider aufgefallen, dass nach dem Reboot die lxcbr0 Bridge nicht immer bereit zu seien scheint und die Adresse nicht zugewiesen wird, hier scheint es also noch Verbesserungspotential zu geben).

    Dies scheint tatsächlich nach keinem Reboot zu funktionieren, weder mit up <...> noch mit post-up <...>. Wie @frank_m schon angedeutet hat ist das möglicherweise auch gar nicht mal die beste Lösung (?).

    Hättet ihr da noch eine Idee?

  • Wie frank_m schon angedeutet hat ist das möglicherweise auch gar nicht mal die beste Lösung (?).

    Ich sehe das Problem nicht. Ggf. hat sich Frank da verguckt.

    Ich benutze hier immer ein Script, welches mir die Adressen zuweist, nachdem das Netzwerk durchlief.


    Die IPv6 kannst du doch auch in der LXC Config für die Bridge zuweisen - evtl. sogar direkt unter /etc/network/interfaces

    Die Bridge selbst steht nämlich solange auf "down", bis der erste Container gestartet ist. Und dieser Zeitpunkt kann halt nach "post up" von ens3 liegen.


    Ich würde sagen, da stimmt etwas in der Logik bzgl. der Startreihenfolge nicht.