Kerusakan jaringan Linux: langkah terbaik untuk mengetahui penyebabnya?

Salah satu server Linux (CentOS) kami tidak dapat dijangkau tadi malam.

Server tidak dapat dijangkau dengan cara apa pun kecuali konsol jarak jauh. Setelah masuk dengan konsol jarak jauh, ternyata saya juga tidak bisa melakukan ping ke host luar.

Sederhana service network restartmemecahkan masalah, tetapi saya masih bertanya-tanya apa yang bisa menyebabkan ini. File log saya sepertinya tidak menunjukkan kesalahan sama sekali (kecuali untuk berbagai daemon yang membutuhkan koneksi jaringan dan gagal setelah kegagalan jaringan).

Adakah langkah tambahan yang bisa saya ambil untuk mencari tahu penyebab masalah ini?

EDIT : ini baru saja terjadi lagi. Server benar-benar tidak responsif sampai saya mengeluarkan restart layanan jaringan. Saran apa pun dipersilahkan. Mungkinkah ini disebabkan oleh komponen perangkat keras yang rusak?

Sesuai permintaan Madhatters, berikut adalah beberapa kutipan dari log pada saat itu (jaringan macet pada 20:13):

/ var / log / messages:

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

Tiga pesan pertama adalah respons sederhana terhadap aturan iptables yang telah saya atur melalui firewall LFD. Pesan terakhir menunjukkan bahwa JungleDisk, yang saya gunakan untuk cadangan tidak dapat lagi terhubung ke gateway. Selain itu, tidak ada pesan menarik di sekitar saat ini.

EDIT 4 Desember: sesuai permintaan Mattdm, berikut adalah output dari ethtool eth0:

(Harap tidak bahwa ini adalah pengaturan yang saat ini berfungsi . Jika ada yang salah lagi, saya akan pastikan untuk memposting ini lagi jika perlu.

Settings for eth0:
        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 auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Sesuai permintaan Joris, berikut juga output dari route -n:

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

Bagian bawah xx.62 adalah gateway saya.

EDIT 28 Desember: masalah terjadi lagi dan saya mendapat kesempatan untuk membandingkan beberapa output dari tes di atas. Apa yang saya temukan adalah bahwa arp -anmengembalikan alamat MAC yang tidak lengkap untuk gateway saya (yang tidak di bawah kendali saya; server berada di rak bersama):

Selama kegagalan:

? (xx.xx.xx.62) at <incomplete> on eth0

Setelah service network restart:

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

Apakah ini sesuatu yang bisa saya perbaiki atau sudah waktunya saya menghubungi pusat data?

memeriksa

dmesg | lessuntuk apa pun yang terkait dengan alias nic Anda (yaitu eht0) less /var/log/messagesjuga

Meskipun jarang itu bisa menjadi konflik alamat ip, jika ini harus terjadi lagi coba

arping -U <gateway ip> -I <nic alias> Namun periksa ini karena sudah lama sejak saya menggunakan arping dan ini mungkin salah.

Jika berhasil, Anda harus mendapatkan kembali koneksi tanpa memuat ulang layanan jaringan.

Bagaimana Anda mendapatkan alamat IP Anda di jaringan ini (DHCP, atau statis)? Jika itu terjadi lagi, pastikan untuk menjalankan ifconfiguntuk melihat kondisi antarmuka saat sedang dalam kondisi non-fungsional. Apakah ada alamatnya? Apakah ada kesalahan? Jika Anda menjalankan ethtool, apakah ada tautan? (Dan apakah itu dinegosiasikan dengan kecepatan dan dupleks yang tepat?)

Berdasarkan masalah yang ditemui, saya akan sangat curiga terhadap konflik alamat IP. Restart jaringan akan mengirim ARP gratis yang akan mengambil alih IP itu lagi, yang akan menghapus semuanya.

Saya akan menginstal arpwatch pada host lain di domain broadcast yang sama (jaringan yang sama) dan melihat apakah ada mesin lain menanggapi permintaan ARP untuk IP server Anda. Jika demikian, cari tahu mesin mana (mungkin menggunakan tabel alamat MAC dari sakelar Anda untuk mengetahui port mana yang dilampirkan) dan setel ke alamat statis atau DHCP lainnya.

Mungkin pool koneksi TCP penuh? Sesuatu membuka semakin banyak koneksi, mungkin mencoba netstat(coba opsi yang berbeda, misalnya -i untuk melihat antarmuka) akan memberikan wawasan tentang koneksi terbuka.

Jika koneksi aktual (dan iptables / rute / apa pun: konfigurasi you_are_using) ok, masalah bisa misalnya dalam konfigurasi antarmuka jaringan.

Apakah ifconfig -aoutput Anda waras? Output itu akan memberi tahu jika Anda memiliki beberapa perangkat jaringan yang seharusnya tidak ada, misalnya perangkat virtual, yang menyebabkan paket-paket menjadi rusak.

Tabel perutean yang Anda tempel ini terlihat sangat aneh. Apakah itu berfungsi ketika seperti itu, dan apakah itu berubah setelah koneksi berhenti berfungsi? Jika ya, ada sesuatu yang menyebabkan tabel routing berubah, mungkin sesuatu yang terkait iptables.

Akhirnya, hal khusus CentOS: apakah Anda memiliki NetworkManager yang digunakan? Ini diaktifkan secara default di CentOS untuk beberapa alasan, bahkan di mesin virtual yang tidak memiliki X, membuat koneksi ini menjadi dua kali lipat, perubahan rute, dan hal-hal lain yang mungkin. Saya sarankan mematikannya kecuali Anda tahu Anda membutuhkannya (seperti, memiliki koneksi yang hidup dan mati).

Masalah ini telah dipecahkan beberapa waktu yang lalu: masalahnya ternyata terkait dengan perangkat keras.

NIC baru telah memecahkan masalah ini.

Dari mana Anda menguji? Di dalam subnet atau di luarnya? Berapa banyak rute yang Anda miliki? Pemilihan gerbang otomatis dapat melakukan hal-hal yang tampaknya tidak dapat diprediksi.

Saya tidak menggunakan RedHat atau CentOS, tetapi cobalah melihat skrip apa pun yang dipanggil saat Anda melakukan. service network restart. Karena jaringan Anda kembali normal ketika sesuatu dalam skrip itu terjadi, mungkin membantu mempersempitnya.

Hhhmm.

Mungkin perubahan tidak sengaja ke iptables? Ini dapat menjelaskan mengapa tidak dapat dijangkau dan mengapa tidak ada yang aneh di log (mungkin Anda tidak login iptables. Kan?)