Beiträge von gschwepp

  • Rancher und Longhorn auf netcup Servern aufbauen. Erfahrungen?

    Hi,

    die RS haben im Gegensatz zu den VPS "dezidierte" Kerne für deine Server. Die stehen dir garantiert zur Verfügung und sollten eig. nicht für andere nutzbar sein.


    Wenn es möglich ist könntest du versuchen den VPS aus dem Cluster zu nehmen und schauen was passiert. Ich habe keine Erfahrung mit rancher oder longhorn, aber es klingt für mich mehr nach einem Verbindungsproblem als nach einem CPU Problem.


    Beste Grüße

  • FreeBSD 12.1 Probleme IPv6

    Hallo zusammen,
    ich denke ich habe jetzt das Problem im Griff. Ich würde meine Erkenntnisse teilen, daher hier nochmal abschließend eine Zusammenfassung:

    Setup:

    OS: FreeBSD 12.1

    Netzwerktreiber: virtio

    Produkt: Root-Server (Mega-Ei OST20)

    IPv4: DHCP

    IPv6: Statisch

    DNS: Netcup

    Problem:

    Die statisch konfigurierte (nach Netcup Anleitung) IPv6 Verbindung ist nicht stabil. Der initiale Ping6 ist extrem verzögert und es kommt zu Paketverlusten. Dieses Phänomen tritt in unregelmäßigen Intervallen ca alle 5-30 Minuten auf. Noch "schlimmer" verhält es sich, wenn versucht wird von außen den Server via IPv6 zu pingen. Es kommt zu Paketverlusten, bis eine Verbindung zustande kommt. Es kam auch vor, dass gar keine Verbindung etabliert wurde.


    Nach der Rückmeldung anderer *BSD Nutzer hier im Forum tritt das dort ebenfalls auf (soweit ich das gelesen habe).


    Um eine Fehlkonfiguration von meiner Seite ausschließen zu können habe ich auch das FreeBSD 12.1 Image von Netcup verwendet und konnte das Problem reproduzieren.

    Analyse:

    Disclaimer: Die Analyse beruht auf reinen Vermutungen. Ich habe leider von Netcup keine Informationen bekommen, ob diese Annahmen korrekt sind oder nicht.

    Anfänglich hatte ich wie oben beschrieben die Vermutung, dass der Fehler im NDP liegt und die Einträge einfach nach sehr kurzer Zeit ungültig sind und dann wieder eine aus unerfindlichen Gründen lange Neighbor Discovery nötig ist. Diese Annahme war nicht korrekt. Nach weiterer Analyse konnte ich (mit Hilfe von Freunden) folgendes feststellen:

    ... Der Gateway für das IPv6 Subnet in dem mein RS hängt scheint 2a03:4000:42::2/48 zu sei; die Default Route liegt aber auf fe80::1%vtnet0. Im tcpdump konnte nun folgendes beobachtet werden: Der ping6 geht über die Default Route raus an google, dass ist soweit alles in Ordnung. Der Netcup Router schickt die Antwort aber über 2a03:4000:42::2 in dessem /48 Subnetz mein /64 Netz liegt und nicht über die Default Route fe80::1%vtnet0. Damit ist Ausgangsrichtung (an fe80::1%vtnet0) ungleich der Eingangsrichtung (zu meiner IP). FreeBSD und vermutlich auch die anderen *BSDs haben damit ein Problem. FreeBSD (*BSD) muss sich regelmäßig mit den beiden Routern sortieren. Sobald alles sortiert ist funktioniert IPv6 normal für eine gewisse Zeit. ...

    Mehr kann man leider vom Server aus nicht wirklich feststellen.


    Anmerkung: Dieses Phänomen tritt unter Linuxen nicht auftritt; im Rescue System (GRML Linux) ist nur der initiale Ping verzögert, danach funktioniert IPv6 wie es soll. Der IPv6 Stack der *BSDs entspricht der freien Referenzimplementierung des Kame-Projektes. Ob die Linux Distributionen sich ebenfalls nach dieser Implementierung richten ist mir unbekannt. Fakt ist, das Problem ist unter FreeBSD zu beobachten und unter GRML Linux nicht.


    Zusätzlich gab es noch weitere Infos:

    ... Von dem was ich hier so gelesen habe ist das inkludierte v6 Netz geswitcht, jedes zus. erworbenes geroutet. Was das im Detail bedeutet weiß ich nicht, ich bin kein Netzwerkspezialist. ...

    Lösung:


    Wie von vmk und angeritten bereits erwähnt ist ein zusätzliches IPv6 Subnetz die Lösung. Wie KB19 es schon richtig geschrieben hat, bedeutet es:

    ... OK, das wird auf eine Adresse Deines primären Subnetzes geroutet, braucht also kein NDP für jede einzelne Adresse. ...


    Zusatzinfo für alle die kein zusätzliches IPv6 Subnetz bekommen haben: Nachdem man das IPv6 Subnetz dem Server zugewiesen hat sind im SCP -> Netzwerk IPv6 zwei Subnetze gelistet. Zuerst das inkludierte Subnetz, mit der Info Gateway fe80::1. Für das zweite zusätzliche Subnetz bekommt man kein Gateway gelistet, sondern eine Routing to IPv6 Adresse. Diese Routing to IPv6 Adresse ist aus dem Adressbereich des inkludierten Netzes.


    Wenn ich nun die Routing to Adresse als statische IPv6 Adresse auf dem Host eintrage bekomme ich eine stabile IPv6 Verbindung ohne initialem Lag, ohne irgendwelche Probleme. (Da das nirgends dokumentiert zu sein scheint hat es doch eine gewisse Zeit gebraucht um das herauszufinden). Auch sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 ist dann nicht mehr nötig. Meine Vermutung ist, dass diese Routing to IPv6 mit dem zusätzlichen Subnetz im Routing von Netcup extra konfiguriert wird und das es dann einer Konfiguration entspricht mit dem FreeBSD (und hoffentlich auch die anderen) IPv6 Stack funktioniert.


    Hinweis: Nach meinen Tests ist die Routing to Adresse die einzige, die problemfrei läuft. Alle anderen Adressen des Subnetzes haben weiterhin das oben beschriebene Problem. Wenn man aber mehr als eine IPv6 Adresse benötigt, z.B. für Jails, kann man problemlos die IPv6 Adressen des zusätzlichen Subnetzes verwenden. Knackpunkt hier: Das Netzwerkinterface (vtnet0 in meinem Fall) muss die Routing to Adresse haben und alle weiteren IPv6 Adressen (aus dem zusätzlichen Subnetz) können dann als alias zugefügt werden. Das ist wichtig, weil sonst logischerweise keine Route vom zusätzlichen Subnetz (über die Adresse des inkludierten Subnetzes) zum Default Gateway fe80::1 möglich ist.


    Das Verhalten kann im Resuce System nachvollzogen werden:

    1. Rescue System booten 2. ip -6 addr add [Subnetz ::2] dev ens3 3. ping6 heise.de

    Der erste Ping ist verzögert und funktioniert danach (zumindest beim meinem RS). Memo die IP sollte nicht die Routing to Adresse sein.

    1. Rescue System booten 2. ip -6 addr add [routing to] dev ens3 3. ping6 heise.de

    Der erste Ping ist nicht verzögert. Alles funktioniert von anfang an.


    Disclaimer: Wieso es funktioniert ist wieder eine Vermutung und ist keine von Netcup gesicherte Aussage.

    Epilog

    Ist bei allen Kunden im inkludierten IPv6 Subnetz der erste IPv6 Ping verzögert? Außerdem, wenn andere Kunden mit einem zusätzlichen IPv6 Subnetz das Verhalten im Rescue System nachvollziehen könnten und hier Feedback geben fände ich das sehr interessant.


    Momentan ist dieser Lösungsweg nur ein 'works on my machine'. Falls diese Lösung anderen hilft wäre hier Feedback schön um den Lösungsweg zu legitimieren.


    Beste Grüße


    PS: Sorry für die wall of text

  • 2002 connection refused von ausländischem Server?

    Hi NiBa,

    ich verwende nur selten mariadb/mysql, aber die vollständige ERROR 2002 Nachricht ist laut Dokumentation:

    Zitat von mariadb manual troubleshooting connection issues
    Code
    ERROR 2002 (HY000): Can't connect to local MySQL server through   socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")

    Deine Beschreibung lässt vermuten, dass du eigentlich über IP/Port mit der Datenbank verbinden möchtest. Ist die Node möglicher fehlerhaft konfiguriert und versucht sich via Unix-Socket anstelle von IP/Port mit der Datenbank zu verbinden?


    Wenn das nicht der Fall ist, deine Node korrekt konfiguriert ist und der Fehler dennoch geworfen wird musst du erst einmal checken ob du eine Verbindung von der Node zum Datenbankserver bekommst. Dazu kannst du einfach entweder ping, traceroute oder netcat verwenden. Du kannst natürlich auch eine SSH Verbindung von Node zum Server aufbauen. Wenn das funktioniert müsste liegt der Fehler wahrscheinlich am Server und es muss Einträge in den mariadb logs geben. Um da weiterhelfen zu können müssten wir die Einträge kennen.


    Beste Grüße

  • FreeBSD 12.1 Probleme IPv6

    Hallo,


    sorry für die späte Antowort. Ich melde mich nochmal zu diesem Thread zurück. Die initiale Verzögerung des Ping6 liegt an der Infrastruktur von Netcup. Der Support dazu:

    Zitat

    Bis die NDPv6 Adjacency erstmalig auf den Routern zustande kommt, erklärt diese Verzögerung.


    Das kann ich soweit akzeptieren. Das jedoch dieses Problem in Intervallen von ca. 5 - 30 Minuten regelmäßig auftritt ist aus meiner Perspektive nicht in Ordnung. Ich habe dann alles möglich selber probiert mit u.a. ein Cronjob der regelmäßig google oder den Gateway pingt. Irgendwann habe ich mir von einem befreundeten FreeBSD Sysadmin gebeten sich es anzuschauen. Hier eine Kurzzusammenfassung der Erkenntnisse (Anmerkung: Das beruht alles auf Vermutungen aufgrund der gesammelten Informationen):


    Der Gateway für das IPv6 Subnet in dem mein RS hängt scheint 2a03:4000:42::2/48 zu sei; die Default Route liegt aber auf fe80::1%vtnet0. Im tcpdump konnte nun folgendes beobachtet werden: Der ping6 geht über die Default Route raus an google, dass ist soweit alles in Ordnung. Der Netcup Router schickt die Antwort aber über 2a03:4000:42::2 in dessem /48 Subnetz mein /64 Netz liegt und nicht über die Default Route fe80::1%vtnet0. Damit ist Ausgangsrichtung (an fe80::1%vtnet0) ungleich der Eingangsrichtung (zu meiner IP). FreeBSD und vermutlich auch die anderen *BSDs haben damit ein Problem. FreeBSD (*BSD) muss sich regelmäßig mit den beiden Routern sortieren. Sobald alles sortiert ist funktioniert IPv6 normal für eine gewisse Zeit. Wieso Linuxe damit keine Probleme haben kann ich nicht sagen.


    Das Problem wäre lösbar, wenn Netcup alles entweder über 2a03:4000:42::2 oder fe80::1%vtnet0.
    @killerbees19: Wenn das zusätzlich gebuchte IPv6 Subnetz wie von angeritten und vmk erwähnt ordentlich geroutet ist, dann tritt das oben geschilderte Problem nicht auf, da Ausgangs- und Eingangsrichtung gleich sind. Es ist sogar möglich, dass sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1 dann nicht mehr nötig ist, weil die NDP Mitteilungen dann von Hosts kommen, die via Link Local erreichbar sind. Und man damit keine 12 Jahre alte Sicherheitslücke wieder öffnen muss.


    Leider muss ich aber sagen, dass der viel gerühmte Netcup Support nicht mit Qualität geglänzt hat. Dieser geht auf meine Frage ob die oben geschilderten Annahmen korrekt sind gar nicht ein und möchten mich mit Verweis auf die oben zitierte Nachticht abspeisen. Daher bleiben es bisher weiterhin nur Vermutungen.


    Daher abschließend meine Frage an angeritten: Musstest du nur das zusätzliche IPv6 Netz dazubuchen, oder musstest du den Support auch noch motivieren irgendwelche Einstellungen vorzunehmen.


    Es wäre schön, wenn man ohne diesen Aufpreis ein ordentliches IPv6 Subnetz unter FreeBSD/*BSDs bekommen könnte.


    Schöne Grüße

  • FreeBSD 12.1 Probleme IPv6

    Hallo,


    ich habe auf meinem RS FreeBSD 12.1 installiert. Es sieht so aus, als ob es Probleme mit dem Neighbor Discovery Protocol gibt. Out of the box funktioniert IPv6 nicht. Ich muss über


    Code
    sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1


    einschalten, dass sich die NDP-Requests auf einen Link bezieht. Das wurde in FreeBSD deaktiviert Grund: https://www.freebsd.org/securi…/FreeBSD-SA-08:10.nd6.asc.


    Prinzipiell funktioniert damit IPv6, jedoch stellt sich noch ein Problem:


    Code
    ping6 google.com
PING6(56=40+8+8 bytes) 2a03:4000:42:1db::1 --> 2a00:1450:4001:806::200e
16 bytes from 2a00:1450:4001:806::200e, icmp_seq=83 hlim=120 time=93.311 ms
16 bytes from 2a00:1450:4001:806::200e, icmp_seq=84 hlim=120 time=3.902 ms
...

    Es vergeht eine Ewigkeit bis der erste Ping durchkommt und hat deutlich längere Laufzeiten als die nachfolgenden Pings. Solange der NDP Eintrag gültig ist funktioniert alles wie gewünscht. Danach dauert der erste Ping wieder sehr lange.


    Woran kann das liegen? Ich würde mich sehr über eine Lösung für das Problem freuen.