Problematisch war/ist das GRO (generic receive offload). Das sorgt dafür, dass eingehende fragmentierte Pakete bereits von der Netzwerkkarte zusammen gesetzt werden und als Ganzes dem Kernel übergeben werden (interessanter Artikel dazu: JLS2009: Generic receive offload [LWN.net] ).
Wir hatten bis Kernel Version ~4.6/4.7 ein Problem damit, wenn wir mit aktivem GRO IPv6 über einen GRE Tunnel sprechen wollten. Alsbald das (fragmentierte?) IPv6 Paket über den Draht wollte, bekam der Kernel Panik. Irgendwo in den Commit-Messages der erwähnten Version findet sich etwas dazu, dass nun endlich GRO für GRE über IPv6 implementiert wurde. Das Offloading war also für v6 zuvor gar nicht implementiert. Zwar bauen wir unsere GRE Tunnel nur über v4 auf und sprechen v6 nur darüber aber vermutlich hat sich der Bug durch die o. g. Implementation beseitigt. Vielleicht trat das Problem auch nur in Zusammenhang mit Virtualisierung auf, jedenfalls laß man im Internet auch nicht allzuviel über dieses Problem. (Wären meine Fähigkeiten im Debuggen besser, hätte ich ein Ticket aufgemacht.)
Aber wir haben immer noch ein Problem mit GRO: Es bremst die Leitung massiv aus. Über deshyper-01 gehen beispielsweise mit aktivem GRO nicht mehr als 100 Mbit/s (bei deshyper-02 (andere Harware) ist es mehr). Das Problem ist nämlich, dass mit aktivem GRO der Hypervisor die Pakete nicht nur „durchschleift“, sondern sie ggf. wieder fragmentieren muss: Die Netzwerkkarte baut fragmentierte Pakete zusammen, diese sind dann größer als 1.5k, Daher muss der Hypervisor sie wieder auseinander nehmen, damit sie ins Interface der VM passen und die VM muss sie wieder zusammen bauen.
Eine potentielle Lösung wäre natürlich die MTU für das Interface zwischen Hypervisor und VM auf 65k oder so zu stellen. Das steht auch noch auf meiner Forschungs-TODO-Liste. Aber mein Gefühl sagt mir, dass wir uns bestimmt etwas anderes damit abschießen.
Um zum Ursprung zurück zu kommen: Da das Problem „Kernelpanic bei IPv6 über GRE bei GRO (auf der physischen NIC)“ ein sehr spezifisches Problem im Linux-Kernel war, denke ich nicht, dass dieses auch in anderen Kerneln wahrscheinlich ist.
Ganzes IP Subnet geht afaik ohne Ausfall, Einzelne IP Adressen und Host-IP mit mehr Aufwand und Downtime oder gegen Geld oder so: https://wiki.hetzner.de/index.php/Root_Server_Upgrades