Schlagwort: netcup

Als Kunden der bei netcup FreeBSD „rootserver“ auf KVM qemu Basis einsetzt, habe ich schnell gemerkt, dass meine IPv6 Verbindung nicht stabil ist.

Dieses zeigt sich wie folgt:

– Direkt nach dem Boot scheinen IPv6 Verbindungen zu funktionieren, wie gewünscht.

– Nach einiger Zeit brechen die Verbindungen zusammen, sowohl Verbindungen vom System in die Welt als auch Verbindungen von der Welt ins System.

– Verbindungen scheinen „Startprobleme“ zu haben. Ein ping läuft erst ein paar Mal ins Leere und dann funktionieren alle Verbindungen plötzlich wieder für einen Moment.

Ein möglicher Workaround ist es, vom System aus einen ping auf die IPv6 Adresse des Gateways von netcup zu starten. Dieses sorgt in der Regel kurzzeitig für funktionsfähige IPv6 Verbindungen. Aber was ist das genaue Problem und wie könnte eine brauchbare Lösung aussehen?

Als Leser mit IPv6 Wissen, denkt man natürlich sofort a NDP das Neighbor Discovery Protocol und ja ich denke genau hier liegt das Problem. Dieses unterscheidet sich zur Implementation bei Linux etwas, daher funktioniert IPv6 im netcup Testsystem problemfrei unter FreeBSD, NetBSD usw. aber nicht. Die Probleme im NDP lassen sich auf dem System schnell wie folgt erkennen:

root@netcup-vps:~ # netstat -s -picmp6
icmp6:
    0 calls to icmp6_error
    0 errors not generated in response to an icmp6 message
    0 errors not generated because of rate limitation
    Output histogram:
        neighbor solicitation: 29
        neighbor advertisement: 10
        MLDv2 listener report: 8
    0 messages with bad code fields
    0 messages < minimum length
    0 bad checksums
    0 messages with bad length
    Input histogram:
        router advertisement: 17
        neighbor solicitation: 633
        neighbor advertisement: 25
    Histogram of error messages to be generated:
        0 no route
        0 administratively prohibited
        0 beyond scope
        0 address unreachable
        0 port unreachable
        0 packet too big
        0 time exceed transit
        0 time exceed reassembly
        0 erroneous header field
        0 unrecognized next header
        0 unrecognized option
        0 redirect
        0 unknown
    0 message responses generated
    0 messages with too many ND options
    0 messages with bad ND options
    423 bad neighbor solicitation messages
    0 bad neighbor advertisement messages
    0 bad router solicitation messages
    0 bad router advertisement messages
    0 bad redirect messages
    0 path MTU changes

Ich habe einige Zeit damit verbracht, mich mit dem Support darüber auszutauschen. Wie immer landet man zuerst in der human firewall, im Anschluss erreichte ich oft Supportmitarbeiter in Ausbildung eines IT Berufes. Zwischenzeitlich wurde mir das Problem von netcup dann auch bestätigt und mit dem Hinweis versehen, dass es an ihren Core-Routern liege, welche irgendwann ein Update bekommen sollen. Wann genau dieses Updates gemacht wird, konnte/wollte mir niemand bestätigen. Ebenfalls wurde versucht mein System auf verschiedene Hosts zu verschieben, von welchen andere Kunden wohl positives berichtet hatten. Dann sollte das Problem irgendwann behoben sein und netcup war erstaunt, dass es dieses noch nicht ist. Was auch immer… Aus meiner Sicht liegt das Problem an netcup.

Gelöst werden kann dadurch, dass man seinem BSD mitteilt, es soll bitte ND nach RFC4861 machen. Dieses ähnelt zumindest im Punkt der Bindung des jeweiligen ND ans Interface. Dafür kann man dieses als kurzen Test wie folgt aktivieren:

sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Stellt sich der gewünschte Erfolg ein, wird es mit dem passenden Eintrag in der /etc/sysctl.conf permanent aktiviert:

net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Dabei aber bitte beachten, dass FreeBSD dieses vor ca. 10 Jahren aus Sicherheitsgründen deaktiviert hat. https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

Ich bin mit meinen Bemühungen aber leider nicht zu einer, für mich funktionierenden, Lösung von Seiten netcups gekommen. Daher blieb mir nur RFC4861.

Ich denke das Problem ist sicher schon lange beim Support bekannt, einfache google Suchen oder im netcup Forum zeigen dieses schnell auf. Dennoch vermittelte der Support mir erst das Gefühl, selbst etwas falsch konfiguriert zu haben, nur um mir dann den Eindruck zu vermitteln, dass sie noch nie von einem solchen Problem gehört haben. Ich vermute daher, dass ihr Setup aktuell einfach keine „einfache“ Lösung dieses Problems zulässt und sie daher so agieren. Was aber natürlich reine Spekulation ist, ich kann auch nur „vor“ das Setup schauen.

Fragen? Dann fragen…