Am Dienstag, dem 05.10.2021 um 10:04 +0200 schrieb Christian Perle:
On Tue, Oct 05, 2021 at 00:54:38 +0200, Daniel Leidert wrote:
gegeben ist folgendes Szenario: Ein kleiner Computer (A) mit Ubuntu mit lediglich einer NIC. Im Normalbetrieb dient die NIC zur Verbindung des Systems mit einem anderen Gerät (B, ebenfalls nur eine NIC, 192.168.1.11). Um das System einzurichten wurde nun A mit dem lokalen Netzwerk (mit Router (C)) verbunden. Dafür bekommt die NIC in A eine IP via DHCP von C zugewiesen (192.168.2.0/24) und hat außerdem eine statische IP gesetzt (192.168.1.1/24), um mit B kommunizieren zu können, wenn verbunden:
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether <..> brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute enp1s0 valid_lft forever preferred_lft forever inet 192.168.2.67/24 brd 192.168.2.255 scope global dynamic noprefixroute enp1s0 valid_lft 257171sec preferred_lft 257171sec
Problem: Im Normalbetrieb treten Aussetzer der Verbindung zwischen A und B auf und wir wissen nicht so recht, warum. EEE wurde schon ausgeschaltet
Mit EEE habe ich keine Erfahrung. Schaltet man sowas per ethtool aus?
Ja. Ich habe dazu einen cron-jon eingerichtet, der beim Reboot läuft. Laut $suchmaschine soll es für die Intel module e1000e und igb auch den Paramter EEE geben, aber das scheint eher eine Legende zu sein *schulterzuck*.
und hat enorm zu einer Stabilisierung beigetragen. Trotzdem ist noch etwas faul. Ich kann aber nicht auf A zugreifen, solange das System mit B verbunden ist.
Hier waere noch wichtig zu wissen, mit welcher Methode das Netzwerk auf Computer A konfiguriert wird. Bei Ubuntu wurde ja dieses obskure "Netplan" eingefuehrt, das anscheinend die Konfigurationsmethode /etc/network/interfaces ersetzt.
network-manager
[..]
Nun dachte ich, dass wenn ich A, B und C mittels Switch verbinde, ich mich sowohl einloggen können müsste (via C -> Switch -> A) als auch die Verbindung mit B sehe (A -> Switch B). Dem Switch müsste das doch völlig egal sein. Das funktioniert aber nicht:
$ ip neigh 192.168.2.64 dev enp1s0 lladdr <..> REACHABLE 192.168.1.11 dev enp1s0 INCOMPLETE 192.168.2.1 dev enp1s0 lladdr <..> DELAY
Das ist vermutlich der "ip neigh"-Output auf Computer A?
Korrekt.
Mittlerweile habe ich die Info bekommen, dass der oben beschriebene Aufbau mit einem neuen Switch problemlos läuft und Gerät B damit erreichbar ist. Mir wurde aber auch berichtet, dass die Verbindung zwischen A und B mit dazwischen geschaltetem Switch nun absolut stabil sei...
A ist eine kleines kompaktes System mit einer Intel I210 (igb Kernelmodul, Kernel 5.8 IIRC, bis 1GB/s). B ist ein schon etwas älterer RFID-Reader mit Hersteller-OS, dessen Netzwerkkarte nur 10/100Mbit/s schafft. Mit EEE spielte die Direktverbindung richtig verrückt, permanent war das Netzwerk down. Ohen EEE läuft es deutlich besser, aber irgendwas scheint immer noch zu stören (nur eben scheinbar nicht, wenn ein Switch dazwischen hängt). Auto-negotiate auf der Intel-NIC ist eingeschaltet. Ich habe schon daran gedacht, auto-negotiate auszuschalten und die Geschwindigkeit manuell auf 100MBit/s und Duplex-Mode auf 'full' zu setzen...
Gruß, Daniel