[Erledigt] Ping Antwort <1ms vs 80ms

[unterwurzer]

Hi,

Ich habe einen Debian Rechner im Netzwerk. Das Netzwerk besteht aus einem Router und 5 PC's.
Der Ping unter den Clients ist kleiner 1ms.
Der Ping zum Debian Rechner ist ~100ms. Alle PC's sind per Kabel mit einen Switch verbunden.

Der Debian PC hat eine Statische IP vergeben.
Nach einen Neustart hat Debian eine Pinglaufzeit <1ms. Nach einiger Zeit (genaue Zeit konnte ich noch nicht feststellen) Ist die Pinglaufzeit plötzlich auf ~100ms. (Performance Einbruch bei samba ENORM)

In der Zwischenzeit wird am PC oder im Netzwek nicht gearbeitet. Wie komme ich nun zur Fehlerursache? Der PC hat eine statische ip per GUI Netzwekmanager vergeben bekommen.
Ich habe zuerst 192.168.0.x verwendet. Durch einen Umzug musste ich nun 10.0.0.x verwenden.

Zuvor hat das Jahrelang funktioniert!!

[mat6937]

Nach einiger Zeit (genaue Zeit konnte ich noch nicht feststellen) Ist die Pinglaufzeit plötzlich auf ~100ms.

Ist die Pinglaufzeit bei jedem Ping ca. 100ms, oder nur beim 1. Ping? Z. B. wenn Du:

Code: Alles auswählen

ping -c 10 <IP-Adresse>

machst?

EDIT:

Sind beim pingen mit dem arp-Protokoll die Zeiten auch so hoch:

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Source-Rechner> <IP-Adresse-Debian-Rechner>

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Debian-Rechner> <IP-Adresse-Router>

[unterwurzer]

Nach einen Neustart gibt es über Stunden eine konstante Anwort <1ms!
Zu einen Zeitpunkt X plötzlich sind die Antworten 70 - 100 ms

Ein paralleler Ping ins Internet ist immer konstant ~80ms

Danke für jede Hilfe!!

Nach einen Neustart: - da ich gerade einen Neustart durchgeführt habe
root@server:~# ping -c 10 10.0.0.100
PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
64 bytes from 10.0.0.100: icmp_req=1 ttl=64 time=0.020 ms
64 bytes from 10.0.0.100: icmp_req=2 ttl=64 time=0.016 ms
64 bytes from 10.0.0.100: icmp_req=3 ttl=64 time=0.015 ms
64 bytes from 10.0.0.100: icmp_req=4 ttl=64 time=0.015 ms
64 bytes from 10.0.0.100: icmp_req=5 ttl=64 time=0.016 ms
64 bytes from 10.0.0.100: icmp_req=6 ttl=64 time=0.016 ms
64 bytes from 10.0.0.100: icmp_req=7 ttl=64 time=0.015 ms
64 bytes from 10.0.0.100: icmp_req=8 ttl=64 time=0.015 ms
64 bytes from 10.0.0.100: icmp_req=9 ttl=64 time=0.015 ms
64 bytes from 10.0.0.100: icmp_req=10 ttl=64 time=0.015 ms

Edit:
zusätzlich Info zum Netzwerk:
http://www.directupload.net/file/d/4129 ... 98_png.htm

[mat6937]

Zu einen Zeitpunkt X plötzlich sind die Antworten 70 - 100 ms

Sind dann zum Zeitpunkt X, beim pingen mit dem arp-Protokoll die Zeiten auch so hoch:

Code: Alles auswählen

sudo apt-get install iputils-arping

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Source-Rechner> <IP-Adresse-Debian-Rechner>

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Debian-Rechner> <IP-Adresse-Router>

[rendegast]

Probiere mal
linux-image-...
firmware-....
aus jessie-backports.

Mal Netzwerkkarte tauschen?

Router-Firmware?

[unterwurzer]

Probiere mal
linux-image-...
firmware-....
aus jessie-backports.

Mal Netzwerkkarte tauschen?

Im Pc sind 2 Netzwerkkarten eingebaut:
1 x Onboard
1 x Seperat (PCI)

Auf beiden Netzwerkkarten zeigt sich das gleiche Fehlerbild. Kabel wurde ausgetauscht.
Derzeit ist nur mehr die PCI am Netzwerk angesteckt mit einer fix konfigurierten IP

ich weis nicht was damit gemeint ist "linux-image-...
firmware-....
aus jessie-backports.
"

[unterwurzer]

Zu einen Zeitpunkt X plötzlich sind die Antworten 70 - 100 ms

Sind dann zum Zeitpunkt X, beim pingen mit dem arp-Protokoll die Zeiten auch so hoch:

Code: Alles auswählen

sudo apt-get install iputils-arping

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Source-Rechner> <IP-Adresse-Debian-Rechner>

Ich habe ein Heterogenes Netzwerk --> Server Linux --> Clients WIN - daher kann ich das so nicht ausführen - mußte in youtube erst lernen was arp ist

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Debian-Rechner> <IP-Adresse-Router>

Derzeit wenn alles gut:

root@server:~# arping -c 5 -b -I eth1 -s 10.0.0.100 10.0.0.138
ARPING 10.0.0.138 from 10.0.0.100 eth1
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE] 1.098ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE] 1.024ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE] 1.097ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE] 1.232ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE] 1.020ms
Sent 5 probes (5 broadcast(s))
Received 5 response(s)

Ich reporte sobald der Fehler wieder auftritt - wahrscheinlich in wenigen Stunden - Ich habe vor dem Posting den Server neu gestartet ;-(

[mat6937]

Schau mal auch mit top (oder gleichwertig), ob zum Zeitpunkt X, evtl. eine Anwendung auf deinem Debian-Rechner hohe CPU-Last verursacht.

[rendegast]

ich weis nicht was damit gemeint ist
"linux-image-...
firmware-....
aus jessie-backports."

jessie-backports ist ein jessie angelehntes Repo mit neueren Software-Versionen
(stammend aus den testing/sid-Repo, auf jessie zurückportiert).


linux-image-... ist der Kernel (Gerätetreiber), momentan dort 4.1,
firmware-... meint evtl. firmware für die Netzwerkkarte, zBsp. firmware-realtek.

Code: Alles auswählen

lspci -nn

Evtl. CPU-firmware
amd64-microcode
intel-microcode (Bestandteil iucode-tool gäbe es auch aus jessie-backports)

[unterwurzer]

Schau mal auch mit top (oder gleichwertig), ob zum Zeitpunkt X, evtl. eine Anwendung auf deinem Debian-Rechner hohe CPU-Last verursacht.

Top bzw. htop ist sauber in beiden fällen (soweit ich das sehe):
CPU: 1-4 langweilen sich
Mem: 200/7920MB
sqp: 0/583Mb

Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.0%sy, 0.0%ni, 99.7%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8110776k total, 474908k used, 7635868k free, 24460k buffers
Swap: 5974008k total, 0k used, 5974008k free, 246144k cached

Danke für den Input!

[unterwurzer]

ich weis nicht was damit gemeint ist
"linux-image-...
firmware-....
aus jessie-backports."

jessie-backports ist ein jessie angelehntes Repo mit neueren Software-Versionen
(stammend aus den testing/sid-Repo, auf jessie zurückportiert).


linux-image-... ist der Kernel (Gerätetreiber), momentan dort 4.1,
firmware-... meint evtl. firmware für die Netzwerkkarte, zBsp. firmware-realtek.

Code: Alles auswählen

lspci -nn

Evtl. CPU-firmware
amd64-microcode
intel-microcode (Bestandteil iucode-tool gäbe es auch aus jessie-backports)

[unterwurzer]

ich weis nicht was damit gemeint ist
"linux-image-...
firmware-....
aus jessie-backports."

jessie-backports ist ein jessie angelehntes Repo mit neueren Software-Versionen
(stammend aus den testing/sid-Repo, auf jessie zurückportiert).


linux-image-... ist der Kernel (Gerätetreiber), momentan dort 4.1,
firmware-... meint evtl. firmware für die Netzwerkkarte, zBsp. firmware-realtek.

Code: Alles auswählen

lspci -nn

Result:
root@server:~# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Sandy Bridge DRAM Controller [8086:0100] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Sandy Bridge PCI Express Root Port [8086:0101] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Sandy Bridge Integrated Graphics Controller [8086:0102] (rev 09)
00:16.0 Communication controller [0780]: Intel Corporation Cougar Point HECI Controller #1 [8086:1c3a] (rev 04)
00:1a.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation Cougar Point High Definition Audio Controller [8086:1c20] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 1 [8086:1c10] (rev b5)
00:1c.4 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 5 [8086:1c18] (rev b5)
00:1c.5 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 6 [8086:1c1a] (rev b5)
00:1c.6 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 7 [8086:1c1c] (rev b5)
00:1c.7 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev b5)
00:1d.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
00:1f.0 ISA bridge [0601]: Intel Corporation Cougar Point LPC Controller [8086:1c4a] (rev 05)
00:1f.2 IDE interface [0101]: Intel Corporation Cougar Point 4 port SATA IDE Controller [8086:1c00] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation Cougar Point SMBus Controller [8086:1c22] (rev 05)
00:1f.5 IDE interface [0101]: Intel Corporation Cougar Point 2 port SATA IDE Controller [8086:1c08] (rev 05)
03:00.0 IDE interface [0101]: VIA Technologies, Inc. PATA IDE Host Controller [1106:0415]
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06) --> abgesteckt
06:00.0 PCI bridge [0604]: Device [1b21:1080] (rev 01)
07:00.0 Ethernet controller [0200]: Intel Corporation 82541PI Gigabit Ethernet Controller [8086:107c] (rev 05) --> in Verwendung

uname -a:
Linux server 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC 2014 x86_64 GNU/Linux


Evtl. CPU-firmware
amd64-microcode
intel-microcode (Bestandteil iucode-tool gäbe es auch aus jessie-backports)

[unterwurzer]

root@server:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
root@server:~# ^C
root@server:~# ethtool -t eth1 offline
The test result is PASS
The test extra info:
Register test (offline) 0
Eeprom test (offline) 0
Interrupt test (offline) 0
Loopback test (offline) 0
Link test (on/offline) 0

[rendegast]

uname -a:
Linux server 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC 2014 x86_64 GNU/Linux

Da gäbe es den Kernel 3.2 aus squeeze-backports.

[r4pt0r]

Welcher Switch/Router wird verwendet? ARP-Caching Einstellungen?
Fritzboxen haben teilweise katastrophale ARP-Caches/Einstellungen... a) extrem anfällig für ARP-cache-poisoning/flooding und b) werden dank bescheuerter Einstellungen veraltete Einträge nicht überschrieben sondern bleiben bis zum Ablauf der TTL erhalten, speziell wenn der Client wechselnd per kabel oder WLAN vebunden wird - der korrekte/neue Eintrag läuft dann früher ab und es wird auf den veralteten Eintrag mit längerer TTL zurückgewechselt! Hatte dank diesem bug häufige Verbindungsab/-einbrüche mit einem Notebook das wechselnd per kabel, wlan und wlan-stick ins LAN verbunden wurde.

Auch mal den arp-cache am client überprüfen und/oder per Wireshark mitschneiden was beim Anstieg der Latenz auf der Leitung los ist.

Wird Namensauflösung im Netz verwendet oder werden Server/Hosts per IP-Adresse angesprochen? Wenn ersteres: gibts hier auffälligkeiten? Wenn DNS verwendet wird deaktiviere den veralteten NETBIOS- und WINS-Schrott auf den Windows-Clients. Die Kisten fangen gerne an sich neben dem zuständigen DHCP- und DNS-Server selber neue Adressen und Namen zu vergeben, das hagelt dann reihenweise Probleme die Windows-Typisch an jedem Client anders ausarten können... Von komplettem Verbindungsverlust bis extrem miesem Durchsatz ist alles dabei...
Gab im Sommer einige Windows 7 Updates die den Mist wieder ganz oder teilweise aktiviert und Gruppenrichtlinien dazu verändert haben - mir sind reihenweise Win-Clients aus dem Netz geflogen und/oder konnten Netzwerkdienste nicht erreichen weil sie u.a. die Namensauflösung per WINS an anderen Clients durchführen wollten (Der Traffic an den DNS-Servern war dafür dann angenehm niedrig....) oder sich einen Client als gateway raussuchten der dann per ICS alles an den richtigen gateway weiterleiten wollte (wo er durch massiven Trafficanstieg sofort geblockt wurde).
arpwatch kann hier sehr gut helfen solche rouge-Nameserver zu entdecken und aus dem Netz zu werfen...

Was samba betrifft (bzw das SMB-protokoll allgemein): Das wird niemals wirklich schnell sein - zu den Gründen gibts mehr als genug threads, auch mit tipps wie man es zumindest erträglich schnell bekommt... An ssh/sftp oder gar NFS wirds aber niemals rankommen...

[unterwurzer]

Welcher Switch/Router wird verwendet? ARP-Caching Einstellungen?

Router: TG588v - 10.5.4.W

Fritzboxen haben teilweise katastrophale ARP-Caches/Einstellungen... a) extrem anfällig für ARP-cache-poisoning/flooding und b) werden dank bescheuerter Einstellungen veraltete Einträge nicht überschrieben sondern bleiben bis zum Ablauf der TTL erhalten, speziell wenn der Client wechselnd per kabel oder WLAN vebunden wird - der korrekte/neue Eintrag läuft dann früher ab und es wird auf den veralteten Eintrag mit längerer TTL zurückgewechselt! Hatte dank diesem bug häufige Verbindungsab/-einbrüche mit einem Notebook das wechselnd per kabel, wlan und wlan-stick ins LAN verbunden wurde.

Es handelt sich hier um einen router der Firma Technicolor. Ich habe während der langen Pinglaufzeit den Router neu gestartet um zu sehen ob es am Router liegt --Leider ohne Erfolg
Lediglich eine Neustart des Servers konnte die Pinglaufzeit wieder normalisieren. Auch der neustart des Netzwerkinterfaces konnte den Fehler nicht beheben.

Auch mal den arp-cache am client überprüfen und/oder per Wireshark mitschneiden was beim Anstieg der Latenz auf der Leitung los ist. --> gute Idee - werde ich machen

Wird Namensauflösung im Netz verwendet oder werden Server/Hosts per IP-Adresse angesprochen? --> ist alles IP basierend
Wenn ersteres: gibts hier auffälligkeiten? Wenn DNS verwendet wird deaktiviere den veralteten NETBIOS- und WINS-Schrott auf den Windows-Clients. Die Kisten fangen gerne an sich neben dem zuständigen DHCP- und DNS-Server selber neue Adressen und Namen zu vergeben, das hagelt dann reihenweise Probleme die Windows-Typisch an jedem Client anders ausarten können... Von komplettem Verbindungsverlust bis extrem miesem Durchsatz ist alles dabei...

Gab im Sommer einige Windows 7 Updates die den Mist wieder ganz oder teilweise aktiviert und Gruppenrichtlinien dazu verändert haben - mir sind reihenweise Win-Clients aus dem Netz geflogen und/oder konnten Netzwerkdienste nicht erreichen weil sie u.a. die Namensauflösung per WINS an anderen Clients durchführen wollten (Der Traffic an den DNS-Servern war dafür dann angenehm niedrig....) oder sich einen Client als gateway raussuchten der dann per ICS alles an den richtigen gateway weiterleiten wollte (wo er durch massiven Trafficanstieg sofort geblockt wurde).
arpwatch kann hier sehr gut helfen solche rouge-Nameserver zu entdecken und aus dem Netz zu werfen...

Was samba betrifft (bzw das SMB-protokoll allgemein): Das wird niemals wirklich schnell sein - zu den Gründen gibts mehr als genug threads, auch mit tipps wie man es zumindest erträglich schnell bekommt... An ssh/sftp oder gar NFS wirds aber niemals rankommen...
--> Wenn die Pinglaufzeit < 1ms ist habe ich mit samba absolut kein Thema. Nur wenn die Pinglaufzeit auf 80-100ms erhöt ist dann dauert das laden ewig

Ich möchte mich an dieser Stelle für deine/eure Inputs bedanken - und hoffe auf weiteren Gedankenaustausch

[unterwurzer]

Zeitpunkt x Identifiziert!!

Nun lief der PC einige stunden durch. Ich konnte nun den Zeitpunkt X identifizieren mit einer Fehlermeldung:
Ping von der Windows Maschinerie zum Router:

Code: Alles auswählen

4.10.2015  4:06:36 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:06:46 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:06:56 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:07:06 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:07:17 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:07:27 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64
04.10.2015  4:07:37 Antwort von 10.0.0.100: Bytes=32 Zeit<1ms TTL=64    --> Ab hier werden die Pinglaufzeiten extrem hoch zw. 30 - 100ms
04.10.2015  4:07:47 Antwort von 10.0.0.100: Bytes=32 Zeit=34ms TTL=64
04.10.2015  4:07:57 Antwort von 10.0.0.100: Bytes=32 Zeit=15ms TTL=64
04.10.2015  4:08:07 Antwort von 10.0.0.100: Bytes=32 Zeit=6ms TTL=64
04.10.2015  4:08:17 Antwort von 10.0.0.100: Bytes=32 Zeit=7ms TTL=64
04.10.2015  4:08:27 Antwort von 10.0.0.100: Bytes=32 Zeit=28ms TTL=64
04.10.2015  4:08:37 Antwort von 10.0.0.100: Bytes=32 Zeit=9ms TTL=64
04.10.2015  4:08:48 Antwort von 10.0.0.100: Bytes=32 Zeit=16ms TTL=64
04.10.2015  4:08:58 Antwort von 10.0.0.100: Bytes=32 Zeit=17ms TTL=64
04.10.2015  4:09:08 Antwort von 10.0.0.100: Bytes=32 Zeit=25ms TTL=64
04.10.2015  4:09:18 Antwort von 10.0.0.100: Bytes=32 Zeit=96ms TTL=64
04.10.2015  4:09:28 Antwort von 10.0.0.100: Bytes=32 Zeit=71ms TTL=64
04.10.2015  4:09:38 Antwort von 10.0.0.100: Bytes=32 Zeit=90ms TTL=64
04.10.2015  4:09:48 Antwort von 10.0.0.100: Bytes=32 Zeit=5ms TTL=64
04.10.2015  4:09:59 Antwort von 10.0.0.100: Bytes=32 Zeit=25ms TTL=64
04.10.2015  4:10:09 Antwort von 10.0.0.100: Bytes=32 Zeit=1ms TTL=64
04.10.2015  4:10:19 Antwort von 10.0.0.100: Bytes=32 Zeit=99ms TTL=6

zur gleichen Zeit gibt es auf der Konsole der Linux Maschine folgende Meldung:

Code: Alles auswählen

[b]Message from syslogd@server at Oct  4 04:07:42 ...
 kernel:[44112.810311] Disabling IRQ #19[/b]

Weitere Information:
Wenn die Pinglaufzeit in Ordnung ist liefert das Netzwerk folgendes:

Code: Alles auswählen

ARPING 10.0.0.138 from 10.0.0.100 eth1
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  0.985ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  1.132ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  1.066ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  1.053ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  1.088ms
Sent 5 probes (5 broadcast(s))
Received 5 response(s)
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=43.7 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=42.9 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=48 time=42.9 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=48 time=42.9 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=48 time=43.1 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=48 time=42.9 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=48 time=42.7 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=48 time=43.1 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=48 time=42.7 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=48 time=42.4 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 42.441/42.976/43.746/0.354 ms
PING 10.0.0.138 (10.0.0.138) 56(84) bytes of data.
64 bytes from 10.0.0.138: icmp_req=1 ttl=64 time=0.631 ms
64 bytes from 10.0.0.138: icmp_req=2 ttl=64 time=0.408 ms
64 bytes from 10.0.0.138: icmp_req=3 ttl=64 time=0.331 ms
64 bytes from 10.0.0.138: icmp_req=4 ttl=64 time=0.349 ms
64 bytes from 10.0.0.138: icmp_req=5 ttl=64 time=0.346 ms
64 bytes from 10.0.0.138: icmp_req=6 ttl=64 time=0.373 ms
64 bytes from 10.0.0.138: icmp_req=7 ttl=64 time=0.310 ms
64 bytes from 10.0.0.138: icmp_req=8 ttl=64 time=0.323 ms
64 bytes from 10.0.0.138: icmp_req=9 ttl=64 time=0.324 ms
64 bytes from 10.0.0.138: icmp_req=10 ttl=64 time=0.298 ms

--- 10.0.0.138 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.298/0.369/0.631/0.093 ms

Wenn das Netzwerk nicht in ordnung bekomme ich folgendes:

Code: Alles auswählen

ARPING 10.0.0.138 from 10.0.0.100 eth1
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  92.144ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  92.101ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  92.126ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  92.054ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  92.037ms
Sent 5 probes (5 broadcast(s))
Received 5 response(s)
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=63.0 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=61.9 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=48 time=60.9 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=48 time=59.9 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=48 time=58.9 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=48 time=57.9 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=48 time=56.9 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=48 time=155 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=48 time=55.0 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=48 time=53.9 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
rtt min/avg/max/mdev = 53.971/68.491/155.968/29.288 ms
PING 10.0.0.138 (10.0.0.138) 56(84) bytes of data.
64 bytes from 10.0.0.138: icmp_req=1 ttl=64 time=98.9 ms
64 bytes from 10.0.0.138: icmp_req=2 ttl=64 time=97.9 ms
64 bytes from 10.0.0.138: icmp_req=3 ttl=64 time=97.0 ms
64 bytes from 10.0.0.138: icmp_req=4 ttl=64 time=96.0 ms
64 bytes from 10.0.0.138: icmp_req=5 ttl=64 time=95.0 ms
64 bytes from 10.0.0.138: icmp_req=6 ttl=64 time=94.0 ms
64 bytes from 10.0.0.138: icmp_req=7 ttl=64 time=92.9 ms
64 bytes from 10.0.0.138: icmp_req=8 ttl=64 time=92.0 ms
64 bytes from 10.0.0.138: icmp_req=9 ttl=64 time=91.0 ms
64 bytes from 10.0.0.138: icmp_req=10 ttl=64 time=89.9 ms

--- 10.0.0.138 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9008ms
rtt min/avg/max/mdev = 89.994/94.498/98.971/2.885 ms

Ich denke nun das es an Debian liegt - da die Pinglaufzeit sich signifikant erhöht zum Zeitpunkt der Konsolen Meldung

[unterwurzer]

Nach einiger Zeit (genaue Zeit konnte ich noch nicht feststellen) Ist die Pinglaufzeit plötzlich auf ~100ms.

Ist die Pinglaufzeit bei jedem Ping ca. 100ms, oder nur beim 1. Ping? Z. B. wenn Du:

Code: Alles auswählen

ping -c 10 <IP-Adresse>

machst?

EDIT:

Sind beim pingen mit dem arp-Protokoll die Zeiten auch so hoch:

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Source-Rechner> <IP-Adresse-Debian-Rechner>

Code: Alles auswählen

sudo arping -c 5 -b -I <Interface> -s <IP-Adresse-Debian-Rechner> <IP-Adresse-Router>

Liefert folgende Antwort:

Code: Alles auswählen

root@server:~# arping -c 5 -b -I eth1 -s 10.0.0.100 10.0.0.138
ARPING 10.0.0.138 from 10.0.0.100 eth1
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  91.725ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  91.694ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  95.651ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  95.628ms
Unicast reply from 10.0.0.138 [30:91:8F:03:CD:BE]  91.606ms
Sent 5 probes (5 broadcast(s))
Received 5 response(s)

[mat6937]

zur gleichen Zeit gibt es auf der Konsole der Linux Maschine folgende Meldung:

Code: Alles auswählen

Message from syslogd@server at Oct  4 04:07:42 ...
 kernel:[44112.810311] Disabling IRQ #19

Evtl. den Kernel mal mit noirqdebug starten und beobachten ob die Pingzeiten dann nach dem Zeitpunkt X, auch ansteigen.
Das ist m. E. dann aber noch nicht die Lösung deines Problems. Man sollte schauen welches device (mit welchem Treiber) diesen Interrupt (der deaktiviert wird) nutzt.

[unterwurzer]

Es ist wohl die Netzwerkschnittstelle ?:
folgendes liefert /proc/interrupts

Code: Alles auswählen

           CPU0       CPU1       CPU2       CPU3
  0:        259          0          0          0   IO-APIC-edge      timer
  1:          2          0          0          0   IO-APIC-edge      i8042
  4:          2          0          0          0   IO-APIC-edge
  5:          0          0          0          0   IO-APIC-edge      parport0
  8:         27          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          4          0          0          0   IO-APIC-edge      i8042
 16:          0          0          0          0   IO-APIC-fasteoi   pata_via
 19:     400001          0          0          0   IO-APIC-fasteoi   eth1                            <<---- Nur was sagt mir das ..?
 20:    1282458          0          0          0   IO-APIC-fasteoi   ata_piix, ata_piix
 22:        425          0          0          0   IO-APIC-fasteoi   HDA Intel
 23:      18688          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2
 29:          0          0          0          0   PCI-MSI-edge      eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:    2331236    3226889    1215604     424890   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
PND:          0          0          0          0   Performance pending work
RES:    1244569      43240      47651       4245   Rescheduling interrupts
CAL:        435        101        473        483   Function call interrupts
TLB:       2805       2035       5529       1265   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:        218        218        218        218   Machine check polls

Hier noch der Auszug der Hardwaremeldung.


Nun muss ich nur noch verstehen wie mann den Treiber updatet und den Kernell updated - OHNE das ich dort hin fahren muss - ist 30 km weiter weg --> steht bei der Fam.

[mat6937]

Es ist wohl die Netzwerkschnittstelle ?:
folgendes liefert /proc/interrupts

Code: Alles auswählen

           CPU0       CPU1       CPU2       CPU3
 19:     400001          0          0          0   IO-APIC-fasteoi   eth1                    <<---- Nur was sagt mir das ..?

Evtl. die Konfiguration bzw. den Treiber der NIC eth1, mal anschauen. Evtl. ein anderes Kabel mal testen und auch mal ohne den Switch testen.

[wanne]

Mich würde massiv interessieren, was die Meldungen davor sind:

Code: Alles auswählen

kernel:[44112.810311] Disabling IRQ #19

Sonst würde ich mal ne andere Netzwerkkarte einbauen. Wette, das Lößt das Problem.

@unterwurzer: Bitte nicht so viel gar so große Schrift.

[rendegast]

Hier noch der Auszug der Hardwaremeldung.

Hätte dieses dmesg nicht eine erste Quelle der Information sein sollen?

Mal nen Speichertest machen?

Zuvor hat das Jahrelang funktioniert!!

Bei dem Spruch gibt es gleich 5% Reparaturaufschlag.

[unterwurzer]

Mich würde massiv interessieren, was die Meldungen davor sind:

Code: Alles auswählen

kernel:[44112.810311] Disabling IRQ #19

Sonst würde ich mal ne andere Netzwerkkarte einbauen. Wette, das Lößt das Problem.

Hier das log:

ct 4 04:07:42 server kernel: [44112.810216] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1
Oct 4 04:07:42 server kernel: [44112.810218] Call Trace:
Oct 4 04:07:42 server kernel: [44112.810220] <IRQ> [<ffffffff81096055>] ? __report_bad_irq+0x30/0x7d
Oct 4 04:07:42 server kernel: [44112.810233] [<ffffffff810961a7>] ? note_interrupt+0x105/0x16e
Oct 4 04:07:42 server kernel: [44112.810237] [<ffffffff8109680c>] ? handle_fasteoi_irq+0x93/0xb5
Oct 4 04:07:42 server kernel: [44112.810242] [<ffffffff8101327f>] ? handle_irq+0x17/0x1d
Oct 4 04:07:42 server kernel: [44112.810245] [<ffffffff810128d9>] ? do_IRQ+0x57/0xb6
Oct 4 04:07:42 server kernel: [44112.810249] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
Oct 4 04:07:42 server kernel: [44112.810251] <EOI> [<ffffffff8102c5f0>] ? native_safe_halt+0x2/0x3
Oct 4 04:07:42 server kernel: [44112.810270] [<ffffffffa016e1ad>] ? acpi_idle_do_entry+0x31/0x58 [processor]
Oct 4 04:07:42 server kernel: [44112.810276] [<ffffffffa016e23c>] ? acpi_idle_enter_c1+0x68/0xb8 [processor]
Oct 4 04:07:42 server kernel: [44112.810282] [<ffffffff8123af86>] ? cpuidle_idle_call+0x94/0xee
Oct 4 04:07:42 server kernel: [44112.810286] [<ffffffff8100fe97>] ? cpu_idle+0xa2/0xda
Oct 4 04:07:42 server kernel: [44112.810291] [<ffffffff8151a140>] ? early_idt_handler+0x0/0x71
Oct 4 04:07:42 server kernel: [44112.810295] [<ffffffff8151acdd>] ? start_kernel+0x3dc/0x3e8
Oct 4 04:07:42 server kernel: [44112.810298] [<ffffffff8151a3b7>] ? x86_64_start_kernel+0xf9/0x106

@unterwurzer: Bitte nicht so viel gar so große Schrift.

--> War keine böse Absicht - Sorry

[unterwurzer]

Es ist wohl die Netzwerkschnittstelle ?:
folgendes liefert /proc/interrupts

Code: Alles auswählen

           CPU0       CPU1       CPU2       CPU3
 19:     400001          0          0          0   IO-APIC-fasteoi   eth1                    <<---- Nur was sagt mir das ..?

Evtl. die Konfiguration bzw. den Treiber der NIC eth1, mal anschauen. Evtl. ein anderes Kabel mal testen und auch mal ohne den Switch testen.

=> Kabel wurde bereits getauscht --> gleiches verhalten
=> Kabel wurde mal über router und mal über 1GB switch angesteckt --> gleiches verhalten