Guten Morgen,
bitte melden Sie sich diesbezüglich beim Support.
Vielen Dank
Guten Morgen,
bitte melden Sie sich diesbezüglich beim Support.
Vielen Dank
Ist das beabsichtigt, dass beim M v6a1 in der Produktbeschreibung "Konsole zur Fernwartung, Backupsystem uvm..." steht, obwohl Snapshots gar nicht möglich sind?
Grundsätzlich finde es etwas ungeschickt, dass bei der Produktbeschreibung keine Details mehr stehen, sondern nur noch bei der Übersicht (und dort erst mit einem Klick sichtbar). Gerade wenn es da deutliche Unterschiede gibt...
Vielen Dank für den Hinweis bezüglich dem Backupsystem. Diesen Fehler haben wir soeben entsprechend korrigiert.
VNC auf englisches Tastatur Layout (en-us) und im OS auch auf Englisch (US) einstellen - dann funktioniert auch das @ auf der deutschen Tastatur. Es funktionieren allerdings dennoch nicht alle Tasten, aber mehr als früher.
Ändert sich etwas am Verhalten wenn die Netzwerkkonfiguration in folgender Weise geändert wird?
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 46.38.235.158
netmask 255.255.248.0
broadcast 46.38.239.255
gateway 46.38.232.1
iface eth0 inet6 static
address 2a03:4000:2:4f4::2
netmask 64
gateway fe80::1
up ip addr change 2a03:4000:2:4f4::2/64 dev eth0 preferred_lft 0
iface eth0 inet static
address 46.38.230.26
netmask 255.255.255.255
iface eth0 inet6 static
address 2a03:4000:20:8::2
netmask 64
up ip addr add 2a03:4000:2:4f4:5054:9bff:fec1:1587/64 dev eth0 preferred_lft 0
Alles anzeigen
Generell ist es so, dass die Zusatz IP's auf die Haupt-IP geroutet werden. Ist die Haupt-IP nicht verfügbar kann logischerweise auch die Zusatz IP nicht erreicht werden.
Rein zum Schutz des Gateways ist es sogar ratsam "accept_ra" zu deaktivieren. Generell unterbinden wir diese Nachrichten auch. In neuen Netzen werden auch das RA komplett deaktivieren, da es sich nicht immer zu 100% zuverlässig verhalten hat. Eine statische Konfiguration ist für öffentliche Server generell die empfohlene Herangehensweise.
Auch wenn im VCP ein anderes Gateway vorgegeben wird?
Ja, man kann auch dann fe80::1 verwenden. Ein anderes Gateway sollte nur noch bei sehr alten Servern der Fall sein.
Ok, denn genau dass hat mich immer bisher etwas verwirrt, denn ich hatte 2a03:4000:XXXX:YYYY:: verwendet gehabt. Dachte man müsste dass übernehmen was angezeigt würde.
Gruß Coolman
Nein man kann von 2a03:4000:XXXX:YYYY:0000:0000:0000:0000 bis 2a03:4000:XXXX:YYYY:FFFF:FFFF:FFFF:FFFF alles verwenden.
2a03:4000:XXXX:YYYY:: ist in erster Linie der Prefix. Inklusive Netzmaske sieht dies dann so aus: 2a03:4000:XXXX:YYYY::/64. Da bei IPv6 die Nullen weglassen werden können und es keine klassischen Netzadressen mehr gibt kann auch 2a03:4000:XXXX:YYYY:: als Adresse verwendet werden. Wir empfehlen aber auf Grund der Eindeutigkeit eine eindeutige IP zu vergeben. Beispielsweise 2a03:4000:XXXX:YYYY::1
Da wir in letzter vermehrt Anfragen zu IPv6 haben möchten wir hier gerne ein kurzes Statement dazu geben.
Sollte die IPv6 Verbindung unterbrochen werden, kann dies auf Grund einer Störung im so genannten Router Advertisment (RA) dazu führen, dass die Server keinen IPv6 Default Gateway mehr erhalten.
Dieses Fehlverhalten kann unterbunden werden, indem der Default Gateway explizit bei der Konfiguration des IPv6 Interfaces angegeben wird.
Der Default Gateway für alle IPv6 Adressen lautet bei der netcup GmbH einheitlich fe80::1.
Eine Beispielkonfiguration für Debian sieht folgendermaßen aus:
Meine Kiste läuft mit CentOS 6.
Wenn die eine Richtung klappt (ausgehend), könnte es auch an der Firewall liegen. centos 6 hat eine default Firewall für IPv6 aktiv:
Behebbar mit:
via How To: Disable Firewall on RHEL / CentOS / RedHat Linux
Hier bitte den netcup Support direkt einschalten. entweder über unsere Homepage oder übers CCP.
Wird eine statische Netzwerkkonfiguration oder DHCP verwendet? Sollte die Netzwerkkonfiguration auf DHCP gestellt sein, bitte auf statisch ändern.
Wir sind dabei den Fehler zu analysieren.
Vielen Dank für die erneute Meldung.
Haben nun noch ein paar Stellen korrigiert. Sind weitere Fehler enthalten?
Vielen Dank für den Hinweis.
Der Fehler wurde soeben korrigiert.
Damit das Problem korrekt untersucht werden kann, ist es wichtig, dass Firewall und ähnliches ausgeschlossen werden kann.Aus diesem Grund ist es ratsam Routing Probleme immer im Rettungssystem zu untersuchen. Unser Rettungssystem ist ein minimal System, hier ist keine Firewall und ähnliches installiert. Sobald hier ein ping möglich ist funktioniert das Routing korrekt, sollte es im Rettungssystem nicht funktionieren bitte einen neuen Support Case aufmachen.
Aus datenschutztechnischen Gründen können alle Informationen die zu der Sperrung geführt haben nur auf E-Mail Adressen die im CCP hinterlegt sind gesendet werden. An "fremde" E-Mailadressen werden keine vertragsrelevanten Informationen gesendet. Sobald im CCP eine gültige Emailadresse hinterlegt ist, kann hier auch eine weitere Handlung erfolgen. Wurde nach der Änderung der E-Mailadresse im CCP schon eine E-Mail mit der Bitte um Zusendung der Sperrinformationen versendet?
In dem Moment in dem eine Sperung erfolgt, werden alle Informationen betreffend der Sperrung direkt an die hinterlegte E-Mailadresse im CCP gesendet.