Interfejs sieciowy zbyt często restartuje się na mennicy 18

Pracuję na zdalnym serwerze przez ssh i zauważyłem, że Vim czasami zamarzł na 5-10 sekund.

ifconfig:

enp0s25   Link encap:Ethernet  HWaddr 28:d2:44:b5:93:fe  
          inet addr:10.30.10.230  Bcast:10.30.255.255  Mask:255.255.0.0
          inet6 addr: fe80::f995:dba3:a12d:bc16/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7745442 errors:8 dropped:1 overruns:0 frame:6
          TX packets:723918 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1036026983 (1.0 GB)  TX bytes:85008484 (85.0 MB)
          Interrupt:20 Memory:f0600000-f0620000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:99543 errors:0 dropped:0 overruns:0 frame:0
          TX packets:99543 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:13269150 (13.2 MB)  TX bytes:13269150 (13.2 MB)

Dmesg pokazuje, że interfejs często rośnie i spada bez żadnego powodu dla mnie (w wyjściu jest o wiele więcej takich linii):

[544981.654197] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[545084.381711] e1000e: enp0s25 NIC Link is Down

uname -a:

Linux farit-PC 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

To Thinkpad T440s.

Jak mogę się upewnić, że nie jest on powiązany z samą Mennicą lub ThinkPadem? Zrobiłem już bilet do naszego zespołu IT za sprawdzenie sieci, ale chciałbym sprawdzić moją stronę.

Może się tak zdarzyć, że ponieważ nie masz kontroli przepływu, jak to napisano w Dmesg, nic nie zrzuca pakietów, gdy inne rzeczy wymagają sieci. Jeśli sieć zostanie przeciążona, zacznie upuszczać pakiety, jeśli nie ma kontroli przepływu. Może być również tak, że coś przeciąża twoją nicość, możesz spróbować to odkryć, utrzymując netstat otwarty i monitorując, czy coś nie otwiera tylko połączeń w sposób ciągły.

Może to również oznaczać, że twoja nisza umiera lub jest wadliwa, co jest jedynym sposobem na poprawienie jej, a zazwyczaj nie jest to ustalane, dopóki nie wykonasz wszystkich kroków w celu naprawienia lub zidentyfikowania przyczyny problemu.

Dane dmesgwyjściowe wskazują najbardziej prawdopodobną przyczynę błędu: stwierdza:

Kontrola przepływu: Brak

Kontrola przepływu (na Wikipedii) to:

proces zarządzania prędkością transmisji danych między dwoma węzłami, aby zapobiec sytuacji, w której szybki nadawca przytłoczy wolny odbiornik.

To dziwne, ponieważ moduł e1000e(a nie moduł e1000, jak początkowo myślałem, że miałeś) ma domyślnie włączony FlowControl . Mogę tylko myśleć o tym, że autonegotiationwyłączyłeś. Spróbuj wydać jako sudo następującą komendę:

ethtool -A enp0s25 autoneg on rx on

przeładuj moduł,

modprobe -r e1000e
modprobe e1000e

(jeśli pierwsze polecenie nie działa, spróbuj wykonać następujące czynności:

ip link set dev enp0s25 down
modprobe -r e10000e
modprobe e1000e
ip link set dev enp0s25 up

powinno działać teraz) i sprawdź, czy nadal występuje ten sam problem. Jeśli to rozwiąże problem, możesz wykonać ethtoolautomatycznie podczas rozruchu, tworząc plik /etc/modprobe.d/e1000e.confz następującą unikalną linią:

post-install e1000e ethtool -A enp0s? autoneg on rx on

To byłaby bardzo dziwna odpowiedź, ale wygląda na to, że był to jakiś przypadkowy błąd.

Z FlowControl nic nie zrobiłem i teraz wszystko działa dobrze. Minął co najmniej tydzień i nie było żadnych problemów.