Serveur inaccessible, meilleure façon de trouver la cause?


1

J'exécute debian squeeze sur un serveur dédié loué et, récemment, le serveur devient de plus en plus inaccessible d'un moment à l'autre avec n'importe quel service externe.

Pendant ce temps d'arrêt, les crontabs, etc. fonctionnent normalement et je ne pouvais trouver aucun incident grave ou lié dans aucun fichier journal.

Pour reprendre le contrôle, je le redémarre simplement via l'interface Web de mon fournisseur.

En ce qui concerne ce sujet: crash réseau Linux: les meilleures étapes pour découvrir la cause? J'ai confronté mon fournisseur à ce problème, mais ils n'ont trouvé aucun problème avec leur carte réseau ou avec la carte réseau. De plus, ils ont complètement modifié le matériel de mon serveur (sauf le disque dur).

Comment puis-je me rapprocher de la source qui est à l'origine de ces temps d'arrêt?

Malheureusement, je n'ai aucun accès au serveur lorsqu'il est externe inaccessible, pour effectuer des tests.

Tant que le serveur est inaccessible, "arp -na" renvoie "à <incomplet> à sur eth0". (J'ai simplement créé une crontab qui vérifie cet état) Dans le syslog, je ne trouve aucune information relative à ce problème.

puck:/home# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
xx.xx.xxx.xxx   0.0.0.0         255.255.255.192 U     0      0        0 eth0
0.0.0.0         xx.xx.xxx.xxx   0.0.0.0         UG    0      0        0 eth0

puck:/home# arp -na
? (xx.xx.xxx.xxx) auf 00:00:5e:00:01:01 [ether] auf eth0

puck:/home# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes

Mes interfaces:

auto lo
iface lo inet loopback

# ethernet interface

auto eth0
iface eth0 inet static
  address xxx.xxx.xxx.xxx
  network xxx.xxx.xxx.yyy
  netmask 255.255.255.yyy
  broadcast xxx.xxx.xxx.255
  gateway xxx.xxx.zzz.zzz

# virtual interfaces

auto eth0:1
iface eth0:1 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.255

auto eth0:2
iface eth0:2 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.255


auto eth0:3
iface eth0:3 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.255

ne les problèmes disparaissent si vous supprimez eth0:1, eth0:2et eth0:3?
Mike Pennington

1
Je renvoie ce problème au fournisseur de services. Il y a beaucoup plus de choses qui peuvent mal tourner en dehors de votre contrôle qui peuvent l'être dans votre contrôle.
womble

Réponses:


1

essayez d'ajouter plus de tâches cron qui s'exécutent toutes les minutes et enregistrez:

  • fait que le travail est exécuté [date >> journal]
  • contenu de la table arp, configuration ip [arp -n >> log; ip a >> log]
  • état de l'interface réseau [ethtool -i eth >> log]
  • enregistrer les messages ne vous fera pas de mal non plus [dmesg -c >> log]
  • résultat du ping au routeur, ping à quelques hôtes 'voisins' du même sous-réseau.
  • forcer la synchronisation pour une bonne mesure

Cela devrait vous aider à déterminer s’il s’agit de l’ensemble de la machine qui gèle ou uniquement des problèmes de réseau et, le cas échéant, par où commencent-ils.

cam it be conflit d'adresse ip ou même mieux cas de dupliquer mac dans le même segment?


Il ne s'agira pas d'une duplication MAC si le fournisseur a permuté le châssis, mais je dirais qu'une collision d'adresses IP est possible, voire improbable, étant donné le symptôme selon lequel un redémarrage est toujours nécessaire (et toujours efficace pendant un certain temps).
womble

Merci pour votre réponse, j'ai ajouté ces informations à ma crontab. De plus, j'ai installé ipwatchd ( ipwatchd.sourceforge.net ) pour contrôler mon ip ... Attendons le prochain temps
mort

@heun ajouter encore plus. tcpdump peut-être quitter après 100 paquets et écrire dans un fichier avec un nom de fichier unique avec horodatage.
pQd
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.