Error Meldung seit heute morgen

  • Hallo ich habe den Server bereits seit min. 2 Monaten am laufen, bis her hatte ich nie eine Fehlermeldung.

    Seit heute morgen habe ich im error log folgende Meldung vorliegen.

    Code
    ICMPv6: RA: ndisc_router_discovery failed to add default route


    Warum ist das so?

  • Hi, ich würde dir gerne helfen, habe aber leider gerade meine Kristallkugel nicht zur Hand :(


    Zitat

    ich habe den Server

    Welchen Server? Welches Produkt? Rootserver? VPS?


    Zitat


    bis her hatte ich nie eine Fehlermeldung

    Nicht eine einzige Fehlermeldung im syslog? Respekt :thumbup:


    Zitat


    habe ich im error log folgende Meldung

    Vielleicht 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

  • 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#IPv6

    Nein die sysclt ist nicht bearbeitet worden, und eine weitere IP habe ich ja nicht

  • 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.

  • 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.

  • 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.