We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

Proxmox - IPv6-Verbindung der VMs bricht ab


Ennercy
13.02.17, 22:03
Zitat Zitat von StevenK
Hi,

nachdem ich die Warteschleife nun mittlerweile auswendig singen kann und das im Schlaf, hier eine Lösung bzw. der Grund des Problems:
Die RAs, welche die Cisco-Router von OVH senden sind irgendwie falsch konfiguriert, damit kommt der Router bzw. die VM nicht klar, da kein Hop über den Server, aber über eine virtuelle Netzwerkkarte ausgeführt wird. - Daher bleibt die Route der VM nur für 1800 Sekunden (30 Minuten) erhalten.

Solang dieses Problem nicht von OVH gefixed ist, sollte man beim dedizierten Server in der /etc/sysctl.conf folgende Einträge haben:
Code:
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.autoconf = 0

net.ipv6.conf.all.proxy_ndp = 1
und bei den virtuellen Maschinen in der /etc/sysctl.conf (vorrausgesetzt, es ist ein Debian/Ubuntu):
Code:
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.ethX.accept_ra=0
net.ipv6.conf.ethX.autoconf=0
Ich hoffe, ich konnte damit einigen weiterhelfen.
danke dir, problem soeben ebenfalls behoben

StevenK
12.02.17, 14:20
Hi,

nachdem ich die Warteschleife nun mittlerweile auswendig singen kann und das im Schlaf, hier eine Lösung bzw. der Grund des Problems:
Die RAs, welche die Cisco-Router von OVH senden sind irgendwie falsch konfiguriert, damit kommt der Router bzw. die VM nicht klar, da kein Hop über den Server, aber über eine virtuelle Netzwerkkarte ausgeführt wird. - Daher bleibt die Route der VM nur für 1800 Sekunden (30 Minuten) erhalten.

Solang dieses Problem nicht von OVH gefixed ist, sollte man beim dedizierten Server in der /etc/sysctl.conf folgende Einträge haben:
Code:
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.autoconf = 0

net.ipv6.conf.all.proxy_ndp = 1
und bei den virtuellen Maschinen in der /etc/sysctl.conf (vorrausgesetzt, es ist ein Debian/Ubuntu):
Code:
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.ethX.accept_ra=0
net.ipv6.conf.ethX.autoconf=0
Ich hoffe, ich konnte damit einigen weiterhelfen.

StevenK
06.02.17, 17:58
im Übrigen geht es „nur“ um die VMs und die Proxmox Kiste war eigentlich zu erreichen über V6
Bei uns genau so - naja, habe mal verwiesen, mal schauen, wie die so darauf reagieren... Falls nicht, rufe ich auch gern in Kanada an und frage die nach Hilfe, was der Support hier zum Scheitern verurteilt ist

RCrave
06.02.17, 17:18
im Übrigen geht es „nur“ um die VMs und die Proxmox Kiste war eigentlich zu erreichen über V6
Kannst ja auch noch auf das Forum verweisen aber ich mach dir wenig Hoffnung auf baldige Lösung da ich 2 Jahre lag immer wieder alles Mögliche gemacht hab.
Vielleicht haben diese 2 Jahre aber doch was ins Rollen gebracht was ich nicht mehr erleben werde.

Ps. es ist egal ob LXC oder KVM….wir haben beides getestet und das gleiche Ergebnis.

StevenK
06.02.17, 17:09
Ja, ich habe die neuste Version... Ich habe vorhin mal mit Herrn Rein gesprochen - ich gebe gleich mal deine Ticketnummer mal weiter, danke.

RCrave
06.02.17, 16:38
Naja da waren wir schon mal ein Stück weiter mit unserem Ticket, es liegt definitiv nicht an Proxmox wenn du die Aktuelle Version 4.xx mit aktuellen Updates hast.
Wir haben auch nix anderes beim neuen Anbieter Installiert als wie bei OVH, aber es läuft auf Anhieb ohne eine einzige Änderung an den VMs Vorzunehmen.
Ein guter Ansprechpartner ist die Frau Thiel, kannst ihr ja mal meine alte Ticket Nummer geben TICKET#9032771110 und ihr einen schönen Gruß Bestellen.

Achja, und ich kann das Verhalten eindeutig Bestätigen, ca. 5-30 Minuten und dann ist IPV6 tot bis die VM einfach neu gestartet wird ohne was dran zu machen.
Und wenn du Glück hast, aber ich spiele kein Lotto, dann kann es sein das nach dem X-sten Neustart IPV6 erhalten bleibt.
Und es ist absolut in keiner Log was zu finden …..aber an die Logs der Router komme ich nicht ran
Es hilft auch nicht alle paar Minuten ein paar Pings an z.B. Google zu schicken, das war mal ist aber vorbei.

StevenK
06.02.17, 15:05
Danke für deine Antwort.

Ich schrieb den OVH-Support bereits an (rief auch an) und als Antwort gab es:
[I]ch habe soeben eine Antwort von einem unserer Techniker erhalten.
Wenn der Server selbst über IPv6 erreichbar ist, handelt es sich hier um ein Software Problem bei der Distribution Proxmox.
Evtl. mach ich nochmal Terror bei der Hotline mit Verweis, dass ich nicht der einzige Kunde bin...

RCrave
06.02.17, 10:13
Zitat Zitat von StevenK
Hat niemand eine Idee?
ja habe ich
Ticket aufmachen und warten bis mal was passiert.
Zu diesem Thema gibt es von unserer Seite ein Ticket welches Monatelang von uns „verfolgt“ wurde aber ohne dass was Wesentliches geschah.
Zum Oberhammer kommt die Tatsache, dass das Ticket mittlerweile nicht mal mehr im Interface zu sehen ist.
Wir haben 2 Jahre lang alles Mögliche versucht V6 stabil ans Laufen zu bekommen, leider nicht möglich
Ende vom Lied ist das ich mal woanders eine frisch gesicherte VM Online genommen hab, ohne Änderungen, nur die IPs angepasst, und läuft und läuft….
Mehr brauch man dazu nicht sagen……
OVH hatte Zugänge zu unserem Monitoring System um sich ein Bild zu machen.
OVH hatte Zugriff auf eine Maschine und die Test VM um das zu prüfen, diese wurden nicht benutzt.

aber schön ist das auch einer mal was dazu schreibt und wir nicht die Einzigen sind die damit gekämpft HABEN.
Leider kann ich dir auch nur meine Leidensgeschichte erzählen und habe keine Lösung gefunden außer einen neuen Hoster zu suchen.




Ps. IPV6 steht mit auf der Website (beim Bestellen) und ich „glaube" das gehört zur Gruppe Netzwerk….ich verstehe aber bis heute nicht warum IPV6 kein SLA Fall ist und diese Frage sollte sich OVH mal stellen.

StevenK
05.02.17, 21:19
Hat niemand eine Idee?

StevenK
30.01.17, 20:11
Aloha (ja, ich weiß, draußen ist es kalt...),

ich habe ein Problem mit meinem dedizierten Server bei SoYouStart im Bezug mit IPv6-Adressen:
Wenn ich eine VM (KVM, mit LXC noch nicht getestet) starte, ist diese sofort mit einer IPv6-Adresse erreichbar - folgende Config wird verwendet:
Code:
iface ens18 inet6 static
	address 2001:41d0:8:XXXX::2d
	netmask 128
	post-up /sbin/ip -f inet6 route add 2001:41d0:0008:42ff:ff:ff:ff:ff dev ens18
	post-up /sbin/ip -f inet6 route add default via 2001:41d0:0008:42ff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del default via 2001:41d0:0008:42ff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del 2001:41d0:0008:42ff:ff:ff:ff:ff dev ens18
	dns-nameservers 2001:4860:4860::8888 2001:4860:4860::8844
Nach ca. 30 Minuten ist der Server dann einfach nicht mehr erreichbar, ein Traceroute sieht dann bspw. so aus:
Code:
Start: Mon Jan 30 20:03:41 2017
HOST: T420Mint                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- fritz.box                                              0.0%    10   16.2  14.5   0.7  16.3   4.8
  2.|-- p200300D29BBF01810000000000000001.dip0.t-ipconnect.de  0.0%    10   16.1  15.9  15.6  16.2   0.0
  3.|-- ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- be100-2.fra-1-a9.de.eu                                 0.0%    10   26.8  26.7  26.5  27.1   0.0
  6.|-- be1-1170.sbg-g1-a9.fr.eu                               0.0%    10   29.7  29.9  29.4  31.1   0.3
  7.|-- vl21.sbg-g1-a75.fr.eu                                  0.0%    10   29.5  29.2  29.0  29.5   0.0
  8.|-- vl1250.rbx-g1-a75.fr.eu                                0.0%    10   37.0  37.0  36.7  37.4   0.0
  9.|-- 2001:41d0:0:5:2::27                                    0.0%    10   35.7  35.8  35.7  36.1   0.0
 10.|-- 2001:41d0:0:5:3::1c9                                   0.0%    10   37.0  75.7  36.7 243.3  71.5
 11.|-- ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0
Wenn ich die VM restarte, ist das Problem wieder temporär behoben, der dedizierte Server ist über IPv6 aber bspw. dauerhaft erreichbar.
Ich habe mir schon Lösungsvorschläge angeschaut, wie bspw. Proxy_NDP in der sysctl.conf des dedizierten auf 1 zu setzen - dies gelingt jedoch ohne Wirkung. (Netzwerk wurde restarted)

Über IPv4 ist der Server jedoch weiterhin normal erreichbar.
Die Netzwerkkonfiguration des dedizierten Servers schaut so aus (bitte schlagt mich nicht, aufgrund der vielen vmbr-Interfaces, ich weiß, dass das ekelhaft aussieht - falls jemand einen Verbesserungsvorschlag dazu besitzt, kann er ihn gern höflich senden, dafür wäre ich sehr dankbar )
Code:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# for Routing
auto vmbr1
iface vmbr1 inet manual
	post-up /etc/pve/kvm-networking.sh
	bridge_ports dummy0
	bridge_stp off
	bridge_fd 0


# vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.
auto vmbr0
iface vmbr0 inet static
	address 176.31.XXX.XXX
	netmask 255.255.255.0
	network 176.31.123.0
	broadcast 176.31.123.255
	gateway 176.31.XXX.XXX
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0

auto vmbr2
allow-hotplug vmbr2
iface vmbr2 inet static
	address 79.137.116.XXX
	netmask 255.255.255.255
	broadcast 79.137.116.255
	gateway 176.31.123.254
	bridge_ports none
        bridge_stp off
        bridge_fd 0

auto vmbr3
allow-hotplug vmbr3
iface vmbr3 inet static
	address 79.137.119.XXX
	broadcast 79.137.119.255
	netmask 255.255.255.255
	gateway 176.31.123.254
	bridge_ports none
	bridge_stp off
	bridge_fd 0
	up /sbin/ip addr add 79.137.119.XXX/32 brd 79.137.119.255 dev vmbr3
	up /sbin/ip addr add 79.137.119.XXX/32 brd 79.137.119.255 dev vmbr3
	up /sbin/ip addr add 79.137.119.XXX/32 brd 79.137.119.255 dev vmbr3

iface vmbr0 inet6 static
	address 2001:41d0:0008:XXXX::
	netmask 64
	post-up /sbin/ip -f inet6 route add 2001:41d0:0008:42ff:ff:ff:ff:ff dev vmbr0
	post-up /sbin/ip -f inet6 route add default via 2001:41d0:0008:42ff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del default via 2001:41d0:0008:42ff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del 2001:41d0:0008:42ff:ff:ff:ff:ff dev vmbr0
Witzig ist auch, dass die /etc/pve/kvm-networking.sh bereits von Installation an in der Config mit drinstand, aber diese Datei gar nicht existiert.

Schon mal vielen Dank für die Bemühungen, sich diesen Beitrag überhaupt durchzulesen.