Error Meldung seit heute morgen
- sv3n
- Erledigt
-
-
Hi, ich würde dir gerne helfen, habe aber leider gerade meine Kristallkugel nicht zur Hand
Zitatich habe den Server
Welchen Server? Welches Produkt? Rootserver? VPS?
Zitat
bis her hatte ich nie eine FehlermeldungNicht eine einzige Fehlermeldung im syslog? Respekt
Zitat
habe ich im error log folgende MeldungVielleicht ein paar zusätzliche Infos? Distribution? Version? Welcher error log?
Vielleicht hilft dir das ja weiter:
https://forum.netcup.de/admini…led-to-add-default-route/
Viele Grüße
marpri
-
Hast du die sysctl entsprechend bearbeitet?
ttps://www.netcup-wiki.de/wiki/Zusätzliche_IP_Adresse_konfigurieren#IPv6
-
Welchen Server? Welches Produkt? Rootserver? VPS?
root Server, RS 1000 G8
Vielleicht ein paar zusätzliche Infos? Distribution? Version? Welcher error log?
Welche Infos werden noch benötigt?
Distribution= Debian 9
error log = kernel
auf gefallen ist es mir Hauptsächlich als ich im scp war, denn dort habe ich ja den Monitor und der war weiß.
Hast du die sysctl entsprechend bearbeitet?
ttps://www.netcup-wiki.de/wiki/Zusätzliche_IP_Adresse_konfigurieren#IPv6Nein die sysclt ist nicht bearbeitet worden, und eine weitere IP habe ich ja nicht
-
Error log war kern.log
-
Wie die Meldung schon sagt, Du hast ein Router Advertisement mit der Ankündigung einer Defaultroute erhalten. Da Du voraussichtlich die Adresse und den Gateway fe80::1 händisch konfiguriert hast, aber, wie H6G schon schrieb, Dein Kernel aber /proc/sys/net/ipv6/conf/eth0/accept_ra_defrtr mit Wert 1 gesetzt haben wird, erscheint der Fehler im dmesg. Eine gleichlautende Default-Route für fe80::1 ist ja bereits vorhanden. dmesg -T sagt Dir wohl, dass es ca. alle fünf Minuten passiert.
Lösung 1: ra_accept_defrtr abdrehen für das Interface, wo es passiert (eth0, ens3, ...)
Lösung 2. ra_accept lassen und den Default GW rausgeben - hat den Nachteil, dass wenn radvd ausfallen sollte, Dein Server seine Defaultroute verliert.
-
Nein die sysclt ist nicht bearbeitet worden, und eine weitere IP habe ich ja nicht
Mach das mal trotzdem bitte, unabhängig davon, ob du eine zusätzliche IP hast, oder nicht.
-
Stimmt ich habe jetzt eine 1 drin.
Lösung 1: ra_accept_defrtr abdrehen für das Interface, wo es passiert (eth0, ens3, ...)
Kann ich das Problemlos machen? Und was soll ich eintragen?
-
-
Also nur BOOLEAN.?
Was ich aber immer noch nicht verstanden habe ist, wie kann sich das ändern wenn ich an den Einstellungen nichts gemacht habe?
-
Nachtrag, da fällt mir gerade noch ein, bevor ich Plesk installiert habe habe ich im SCP -> Produkte -> Mein RS -> rDNS geändert, von v234....bestserver.de zu cp.meinedomain.de.
Und den eintag auch noch in die /etc/hosts gemacht (IP Adresse ist geblieben) nur den obigen Namen.
Kann es denn sein das dadurc auch der Fehler enstand? bzw. Fehler immer noch vorhanden ist.
-
Nachtrag, da fällt mir gerade noch ein, bevor ich Plesk installiert habe habe ich im SCP -> Produkte -> Mein RS -> rDNS geändert, von v234....bestserver.de zu cp.meinedomain.de.
Und den eintag auch noch in die /etc/hosts gemacht (IP Adresse ist geblieben) nur den obigen Namen.
Kann es denn sein das dadurc auch der Fehler enstand? bzw. Fehler immer noch vorhanden ist.Das eine hat mit dem anderen nichts zu tun. Wahrscheinlich hast Du /etc/network/interfaces editiert - oder das neuere Äquivalent „netplan“.
Der Fehler wird ja nur ausgegeben, wenn schon eine idente (Default)Route vorhanden ist.
-
Ich habe weder die eine noch die andere Datei geändert.
Mittlerweile ist es so das es bereits schon nach einer Neuinstallation auftritt obwohl am Server nur keyhelp installiert ist und nicht weiteres.
Selbst wenn ich den Server mit VestaCP oder Froxlor neu installiere bekomme ich den Fehler.
-
Nochmal einen Nachtrag, jetzt ist es so das wenn ich eine Neuinstallation durchgeführt habe reines Debian 9 aus dem SCP der Fehler auch auftritt.
-
Nun... schau eben, ob die Route auf der Neuinstallation statisch gesetzt ist. Im Grunde könnten sich auch dhcpv6 und radvd in die Quere kommen, wenn es kein assisting mode ist - dann sollte man das eventuell einmal melden.
Aber ich sehe das offengestanden nicht als Fehler, nur weil Dein Kernellog zugespammt wird. Wie Du das abschalten kannst, haben wir ja schon geschrieben: temporär mittels echo 0 | tee ... oder echo 0 > ... oder dauerhaft via sysctl.conf.
Ich habe bei mir die fe80::1 als Gateway statisch gesetzt und ra_accept_defrtr auf 0 gesetzt. Bei mir läuft das Log in der Konstellation nicht mehr voll, und die Verbindung ist auch da.