☰

Warum funktioniert eine vor dem Start der virtuellen Maschine hinzugefügte IPv6-Route nicht?

tag-icon • tag-icon linux kvm-virtualization ipv6 ping
Warum funktioniert eine vor dem Start der virtuellen Maschine hinzugefügte IPv6-Route nicht?

Ich habe einen externen Server bei Hetzner mit Debian 7 und versuche, KVM mit IPv6-Routing einzurichten (das gleiche Setup funktioniert problemlos für IPv4).

Ich habe eine Ubuntu Server VM mit zwei Schnittstellen, die sich in zwei verschiedenen Subnetzen befinden. Die erste Schnittstelle ist über eine Bridge mit dem Host verbunden:

Host-eth0 <-- external bridge --> vnet0-VM-vnet1 <-- internal bridge

Ich habe die Bridge so konfiguriert, dass über die erste VM-Schnittstelle eine statische Route zum zweiten Subnetz hinzugefügt wird:

ip -6 route add 2a01:4f8:X:Y:2::/80 via 2a01:4f8:X:Y:1::3 dev virbr_external

Dadurch wird der Routeneintrag VOR dem Start der VM hinzugefügt. Wenn ich ping6 vom Host zur vnet1-Schnittstelle (2::2) verwende, erhalte ich diese Fehlermeldung:

ping: sendmsg: Network is down

Wenn ich die Route nicht in der Schnittstellenkonfiguration hinzufüge und sie manuell aufrufe, NACHDEM die VM gestartet wurde, funktioniert alles.

Meine Frage ist also, warum das Routen-Hinzufügen für IPv6-Adressen erst funktioniert, nachdem die VM gestartet wurde?

Zusätzliche Konfigurationsdetails:

Host-Schnittstellen

auto lo
iface lo inet6 loopback

auto eth0
iface eth0 inet6 static
    address 2a01:4f8:X:Y:0::2
    netmask 128
    gateway fe80::1

# Bridge between Host and VM
auto virbr_external
iface virbr_external inet6 static
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    address 2a01:4f8:X:Y:1::2
    netmask 80

up ip -6 route add 2a01:4f8:X:Y:2::/80 via 2a01:4f8:X:Y:1::3 dev virbr_external

# Bridge between VM and other VMs
auto virbr_internal
iface virbr_internal inet6 manual
    bridge_ports none
    bridge_stp off
    bridge_fd 0

VM-Schnittstellen

auto lo
iface lo inet6 loopback

auto eth0
iface eth0 inet6 static
    address 2a01:4f8:X:Y:1::3
    netmask 80
    gateway 2a01:4f8:X:Y:1::2

auto eth1
iface eth1 inet6 static
    address 2a01:4f8:X:Y:2::2
    netmask 80

Bitte sagen Sie mir, ob Sie weitere Protokolle benötigen (bevor und nachdem es funktioniert), ich werde sie dann sammeln.

Antwort1

Ich habe hier das gleiche Problem. Die Lösung besteht darin, den IPV6-Routencache nach dem Festlegen der Route zu leeren:

ip -6 route flush cache

Ändern Sie Ihren Schnittstellenabschnitt in:

...
auto virbr_external
iface virbr_external inet6 static
   bridge_ports none
   bridge_stp off
   bridge_fd 0
   address 2a01:4f8:X:Y:1::2
   netmask 80
   up ip -6 route add 2a01:4f8:X:Y:2::/80 via 2a01:4f8:X:Y:1::3 dev virbr_external
   up ip -6 route flush cache # Flush cache after setting route
   ...

behebt das Problem beim Booten.

Antwort2

Ich bin nicht sicher, ob es mit der Reihenfolge zu tun hat, in der VMs gestartet/Routen hinzugefügt werden, es sei denn, es gibt eine Logik, um die Metrik niedriger als bei anderen Routen festzulegen ... Möglicherweise möchten mehrere Schnittstellen Ihren IPv6-Verkehr weiterleiten, und der Kernel wählt die Route mit der niedrigsten Metrik aus.

Auf meinem System war die Standardmetrik für meine Bridge 425. Wenn also eine VM startet und eine Standardroute mit der Metrik 256 einrichtet, hat diese Vorrang vor der Standardroute bridge0 und bewirkt, dass der Datenverkehr standardmäßig an meine VM gesendet wird. Die Route kann wie folgt ausgedruckt werden:

ip -6 route show

Libvirt sollte dieser Schnittstelle wahrscheinlich nicht einmal erlauben, eine IPv6-Adresse und Routen zu haben, da sie Teil der Bridge ist, aber sie tut es. Daher besteht meine Problemumgehung einfach darin, die Standardroute der Bridge auf einen niedrigeren Wert als die VMNET-Schnittstelle einzustellen. Mit dem Netzwerkmanager:

nmcli connection modify bridge0 ipv6.route-metric 128

Obwohl libvirt jetzt eine Route auf der vnet0-Schnittstelle erstellt, wird diese nicht verwendet, da die Brücke Vorrang hat.

DasFehlerberichtscheint damit zusammenzuhängen, obwohl es sehr alt ist, sodass es sich bei dem Fehler, den ich sehe, möglicherweise um einen neueren handelt ...

verwandte Informationen