Adaptor jaringan Windows Server 2008 R2 berhenti bekerja, membutuhkan reboot keras

TL; versi DR: Ternyata ini adalah bug jaringan Broadcom yang mendalam di Windows Server 2008 R2. Mengganti dengan perangkat keras Intel memperbaikinya. Kami tidak menggunakan perangkat keras Broadcom lagi. Pernah.

Kami telah menggunakan HAProxy bersama dengan detak jantung dari proyek Linux-HA. Kami menggunakan dua instance linux untuk menyediakan failover. Setiap server memiliki IP publik mereka sendiri dan satu IP tunggal yang dibagi antara keduanya menggunakan antarmuka virtual (eth1: 1) di IP: 69.59.196.211

Antarmuka virtual (eth1: 1) IP 69.59.196.211 dikonfigurasi sebagai gateway untuk server windows di belakangnya dan kami menggunakan ip_forwarding untuk merutekan lalu lintas.

Kami mengalami pemadaman jaringan sesekali di salah satu server windows kami di belakang gateway linux kami. HAProxy akan mendeteksi server sedang luring yang dapat kami verifikasi dengan melakukan remoting ke server yang gagal dan mencoba melakukan ping gateway:

Pinging 69.59.196.211 dengan 32 byte data:
Balas dari 69.59.196.220: Host tujuan tidak dapat dijangkau.

Berjalan arp -adi server yang gagal ini menunjukkan bahwa tidak ada entri untuk alamat gateway (69.59.196.211):

Antarmuka: 69.59.196.220 --- 0xa
Alamat Internet Jenis Alamat Fisik
69.59.196.161 00-26-88-63-c7-80 dinamis
69.59.196.210 00-15-5d-0a-3e-0e dinamis
69.59.196.212 00-21-5e-4d-45-c9 dinamis
69.59.196.213 00-15-5d-00-b2-0d dinamis
69.59.196.215 00-21-5e-4d-61-1a dinamis
69.59.196.217 00-21-5e-4d-2c-e8 dinamis
69.59.196.219 00-21-5e-4d-38-e5 dinamis
69.59.196.221 00-15-5d-00-b2-0d dinamis
69.59.196.222 00-15-5d-0a-3e-09 dinamis
69.59.196.223 ff-ff-ff-ff-ff-ff statis
224.0.0.22 01-00-5e-00-00-16 statis
224.0.0.252 01-00-5e-00-00-fc statis
225.0.0.1 01-00-5e-00-00-01 statis

Pada linux gateway, instance arp -amenunjukkan:

peak-colo-196-220.peak.org (69.59.196.220) di <lengkap> pada eth1
stackoverflow.com (69.59.196.212) pada 00: 21: 5e: 4d: 45: c9 [ether] di eth1
peak-colo-196-215.peak.org (69.59.196.215) pukul 00: 21: 5e: 4d: 61: 1a [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) pada 00: 21: 5e: 4d: 38: e5 [ether] on eth1
peak-colo-196-222.peak.org (69.59.196.222) pada 00: 15: 5d: 0a: 3e: 09 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) pukul 00: 26: 88: 63: c7: 80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) pukul 00: 21: 5e: 4d: 2c: e8 [ether] on eth1

Mengapa arp sesekali mengatur entri untuk server yang gagal ini sebagai <tidak lengkap>? Haruskah kita mendefinisikan entri arp kita secara statis? Saya selalu meninggalkan arp sendiri karena berfungsi 99% dari waktu, tetapi dalam contoh ini tampaknya gagal. Apakah ada langkah pemecahan masalah tambahan yang dapat kami ambil untuk membantu menyelesaikan masalah ini?

HAL-HAL YANG KAMI TELAH MENCOBA

Saya menambahkan entri arp statis untuk pengujian pada salah satu gateway linux yang masih tidak membantu.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

Mem-boot ulang server web windows memecahkan masalah ini untuk sementara waktu tanpa ada perubahan lain pada jaringan tetapi pengalaman kami menunjukkan bahwa masalah ini akan kembali.

Tukar kartu dan sakelar jaringan

Saya perhatikan lampu tautan pada port switch untuk server windows yang gagal berjalan pada 100Mb bukannya 1Gb pada antarmuka yang gagal. Saya memindahkan kabel ke beberapa port terbuka lainnya dan tautannya menunjukkan 100Mb untuk setiap port yang saya coba. Saya juga menukar kabel dengan hasil yang sama. Saya mencoba mengubah properti dari kartu jaringan di windows dan server terkunci dan memerlukan reset keras setelah mengklik berlaku. Server windows ini memiliki dua antarmuka jaringan fisik jadi saya telah menukar kabel dan pengaturan jaringan pada dua antarmuka untuk melihat apakah masalahnya mengikuti antarmuka. Jika antarmuka publik turun lagi kita akan tahu bahwa itu bukan masalah dengan kartu jaringan.

(Kami juga mencoba sakelar lain yang kami miliki, tidak ada perubahan)

Mengubah versi driver perangkat keras jaringan

Kami memiliki masalah yang sama dengan driver Broadcom terbaru, serta driver bawaan yang dikirimkan di Windows Server 2008 R2.

Mengganti kabel jaringan

Sebagai upaya terakhir kami ingat perubahan lain yang terjadi adalah penggantian semua kabel patch antara server / switch kami. Kami telah membeli dua set, satu hijau dengan panjang 1ft - 3ft untuk antarmuka pribadi dan satu lagi kabel merah untuk antarmuka publik. Kami mengganti semua kabel tambalan antarmuka publik dengan merek yang berbeda dan menjalankan server kami tanpa masalah selama seminggu penuh ... aaaaa dan kemudian masalah muncul kembali.

Nonaktifkan checksum offload, hapus TProxy

Kami juga mencoba menonaktifkan TCP / IP checksum offload di driver, tidak ada perubahan. Kami sekarang mengeluarkan TProxy dan pindah ke x-forwarded-forpengaturan jaringan yang lebih tradisional tanpa menulis ulang alamat IP mewah. Kami akan melihat apakah itu membantu.

Ganti penyedia Virtualisasi

Jika ini terkait dengan Hyper-V dalam beberapa cara (kami meng-host Linux VM di atasnya), kami beralih ke VMWare Server. Tidak ada perubahan.

Ganti model host

Kami telah mencapai ujung dari tali pemecahan masalah kami dan sekarang secara resmi melibatkan dukungan Microsoft. Mereka merekomendasikan untuk mengubah model host:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Kami melakukan itu, dan kami juga mendapatkan beberapa perbaikan terbaru kernel yang tidak dipublikasikan yang mungkin digulirkan ke 2008 R2 SP1. Tidak memperbaiki

Mengganti perangkat keras kartu jaringan

Pada akhirnya, mengganti perangkat keras jaringan Broadcom dengan perangkat keras jaringan Intel memperbaiki masalah ini untuk kami. Jadi saya cenderung berpikir bahwa driver Broadcom Windows Server 2008 R2 salah!

http://blog.serverfault.com/post/broadcom-die-mutha/

Dari http://linux-ip.net/html/ether-arp.html :

Jika tidak ada entri cache ARP untuk IP tujuan yang diminta, kernel akan menghasilkan permintaan ARP mcast_solicit hingga menerima jawaban. Selama periode penemuan ini, entri cache ARP akan terdaftar dalam keadaan tidak lengkap. Jika pencarian tidak berhasil setelah jumlah permintaan ARP yang ditentukan, entri cache ARP akan terdaftar dalam keadaan gagal. Jika pencarian tidak berhasil, kernel memasukkan respons ke dalam cache ARP dan mereset konfirmasi dan memperbarui timer.

Sepertinya kotak gateway Anda tidak merespons (atau merespons terlalu lambat) permintaan ARP dari kotak gateway Anda. Apakah itu <incomplete>akhirnya beralih ke <failed>? Perangkat keras jaringan apa yang Anda miliki antara server dan gateway? Apakah mungkin permintaan broadcast ARP sedang difilter atau diblokir di suatu tempat antara dua host?

Ini berarti bahwa Anda melakukan ping alamat, IP memiliki catatan PTR (karena itu namanya) tetapi tidak ada jawaban dari mesin yang bersangkutan. Ketika kita melihat ini, hal itu paling umum disebabkan oleh subnet mask yang disetel secara tidak benar - atau dalam kasus IP terikat ke antarmuka loopback yang secara tidak sengaja terikat ke antarmuka eth.

Apa itu 196.220? Apa hubungannya dengan 196.211? Saya berasumsi bahwa .220 adalah salah satu host Proxy HA. Ketika Anda menjalankan ifconfig -a & arp -a di atasnya apa yang ditampilkan?

Seperti yang dikatakan Max Clark, <lengkap> berarti 69.59.196.211 telah mengeluarkan permintaan ARP untuk 69.59.196.220 dan belum menerima tanggapan. (Di Windows-land Anda akan melihat ini sebagai pemetaan ARP untuk "00-00-00-00-00-00" ... Tampaknya aneh bagi saya, BTW, bahwa Anda tidak melihat pemetaan ARP pada 69.59.196.220 untuk 69.59.196.211.)

Saya cenderung tidak suka menggunakan entri ARP statis karena, dalam pengalaman saya, ARP umumnya melakukan tugasnya sepanjang waktu.

Jika itu saya, saya akan mengendus antarmuka Ethernet yang sesuai pada mesin Windows "gagal" (69.59.196.220) untuk mengamatinya ARP'ing untuk 69.59.196.211, dan untuk mengamati bagaimana / jika itu menanggapi permintaan ARP dari 69.59. 196.211. Saya juga akan mempertimbangkan mengendus pada mesin gateway untuk ARP saja ( tcpdump -i interface-name arp) untuk melihat seperti apa traffic ARP dari sisi mesin Linux.

Saya tahu, dari blog , bahwa Anda memiliki jaringan back-end dan jaringan front-end. Selama pemadaman ini, apakah server Windows "gagal" (69.59.196.220) memiliki masalah berkomunikasi dengan mesin lain di jaringan front-end, atau apakah itu hanya mengalami masalah berbicara dengan gateway-nya? Saya ingin tahu apakah Anda datang di mesin gagal melalui jaringan front-end atau back-end ketika Anda menangkapnya dalam tindakan.

Apa yang Anda lakukan untuk "menyelesaikan" masalah ketika itu terjadi?

Edit:

Saya melihat dari pembaruan Anda bahwa Anda me-reboot mesin Windows "gagal" untuk menyelesaikan masalah. Sebelum Anda melakukannya lain kali, dapatkah Anda memverifikasi bahwa mesin Windows dapat "berbicara" pada antarmuka front-end-nya? Juga, ambil salinan tabel perutean dari mesin Windows ( route print) selama kegagalan juga. (Saya mencoba untuk memastikan apakah NIC / driver akan gila pada mesin Windows, pada dasarnya.)

Dokumen ini menunjukkan status yang berbeda (tabel 2.1). Tidak lengkap berarti telah mengirim permintaan ARP pertama (mungkin setelah basi, penundaan, penyelidikan) tetapi belum menerima tanggapan.

Alasan statis ARP pada haproxy node tidak membantu adalah bahwa server web Anda masih tidak dapat menemukan cara untuk kembali ke gateway.

ARP statis pada server web merusak kemampuan server web Anda untuk beralih gateway ketika salah satu node haproxy gagal - Saya menduga antarmuka virtual berbagi alamat MAC yang sama dengan eth1 simpul haproxy, jadi Anda harus kode ke salah satu dari dua gateway ke setiap server web.

Apakah Anda memiliki jenis perangkat lunak keamanan yang diinstal pada server web yang gagal? Saya menghabiskan malam yang panjang dengan server Windows 2008 yang memiliki Symantec Endpoint Security di dalamnya - ia menginstal beberapa kode penyaringan dalam tumpukan jaringan yang mencegahnya melihat paket ARP gateway sama sekali. Perbaikan untuk itu (seperti yang disediakan oleh Microsoft) adalah untuk menghapus entri registri yang memuat DLL.

Lain kali masalah ini terjadi, menghapus seluruh adapter jaringan dari manajer perangkat dan menginstal ulang sepertinya membantu.

Karena Anda telah menetapkan entri arp Anda secara statis, server Anda tahu di mana menemukan gateway. Namun, jika sakelar Anda tidak tahu di mana gateway itu berada, itu tidak akan meneruskan paket Anda.

Kedengarannya Anda mengalami pergantian yang buruk (atau bingung) antara HAproxy dan server web Anda. Mulai ulang.

Entah itu, atau server HAproxy Anda tidak setuju tentang yang mana di kontrol, dan keduanya menjawab pencarian arp untuk .211.

Sepanjang jalur yang sama, jika saklar Anda kelebihan beban, HAproxies Anda mungkin tidak dapat berkomunikasi satu sama lain dengan cepat, dan gagal.

Lain kali masalah ini terjadi, saya akan menyarankan menjalankan beberapa paket menangkap dua host yang bersangkutan, untuk menentukan lalu lintas ARP apa yang masing-masing amati.

Mesin HAproxy Anda kemungkinan besar akan memiliki beberapa rasa tcpdump diinstal. Untuk mesin Windows Anda akan memerlukan aplikasi WinPCAP , seperti Wireshark , atau Microsoft Network Monitor .

Bahkan, memikirkannya, karena masalahnya muncul dengan ARP secara khusus, Anda berpotensi dapat terus-menerus merekam semua lalu lintas ARP pada mesin HAproxy dan mesin Windows yang bersangkutan, dengan file tangkap bergulir (demi argumen) 10MB. Itu harus cukup besar sehingga pada saat Anda mendeteksi kegagalan, file tangkap masih akan berisi lalu lintas ARP dari sebelum kegagalan. (Perlu bereksperimen dengan menjalankan tangkapan selama satu jam atau lebih, untuk melihat berapa banyak data yang dihasilkannya).

Contoh ambil sintaks untuk tcpdump Linux (catatan, saya tidak punya kotak Linux yang berguna untuk mengujinya; harap uji perilaku -C dan -W sebelum menggunakan dalam produksi!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Mudah-mudahan ini akan memberi Anda beberapa indikasi tentang apa yang sebenarnya gagal. Ketika entri ARP kedaluwarsa (dan menurut artikel ini , versi Windows yang lebih baru nampak menjadi usang entri 'tidak aktif' dengan sangat agresif), saya berharap hal berikut terjadi:

1. Host sumber akan mengirimkan permintaan ARP ke host target. Permintaan ARP umumnya disiarkan, tetapi dalam kasus di mana host me-refresh entri yang ada, ARP dapat dikirim secara unicast.
2. Host target akan merespons dengan balasan ARP. 99% dari waktu ini adalah unicast, tetapi RFC mengizinkan tanggapan siaran. (Lihat juga RFC tentang Deteksi Tabrakan Alamat IPv4 untuk detail lebih lanjut).

Sesederhana kedengarannya, ada banyak hal lain yang dapat mengganggu proses ini:

• Permintaan asli mungkin tidak sampai pada target.
• Permintaan mungkin sampai pada target, tetapi responsnya mungkin tidak mencapai sumbernya.
• Beberapa jenis mekanisme ketersediaan tinggi mungkin mengganggu perilaku ARP yang 'normal':
  • Bagaimana cara kerja failover di antara node HAProxy? Apakah itu menggunakan alamat MAC bersama, atau apakah menggunakan ARP serampangan untuk gagal alamat IP di antara node?
  • Banyak alamat MAC dalam tabel ARP di atas dimulai dengan 00-15-5D, yang tampaknya terdaftar di Microsoft. Apakah Anda menggunakan segala bentuk pengelompokan atau HA lainnya pada mesin Windows yang dimaksud? Apakah alamat MAC 00-15-5D ini sama dengan yang Anda lihat terkait dengan NIC perangkat keras ketika Anda melakukan 'ipconfig / all' di server Windows?

Hal-hal untuk memeriksa apakah / ketika ini terjadi lagi:

• Lihatlah tangkapan paket lalu lintas ARP; apakah ada bagian dari percakapan yang jelas tidak terjadi?
• Periksa tabel bridging / CAM switch; apakah semua alamat MAC dalam peta pertanyaan ke port yang Anda harapkan?
• Apakah host lain di subnet memiliki entri ARP yang valid untuk alamat IP dari host Windows dan HAProxy?
• Apakah entri ARP untuk IP target yang sama pada beberapa mesin sumber berbeda menyelesaikan ke alamat MAC yang sama? yaitu masuk ke beberapa host lain di subnet dan verifikasi bahwa 196.211 memutuskan untuk alamat MAC yang sama pada keduanya.

Kami memiliki masalah yang sama dengan salah satu server terminal R2 2008 kami di mana semua lalu lintas di NIC akan berhenti tetapi tetap terhubung, dan LED NIC akan menunjukkan koms. Ini adalah masalah yang sedang berlangsung yang terus memangkas 2-3 kali seminggu, tetapi hanya setelah sekitar 12-13 jam uptime (server reboot setiap malam).

Saya menemukan Seriousbit Netbalancer adalah penyebabnya, setelah saya mencoba (karena penasaran) menghentikan layanan NetbalancerService. Lalu lintas mulai bergerak melintasi antarmuka. Sejak itu saya menghapus instalan Netbalancer.

Saya memiliki masalah yang sama dengan Asus Mainboard lan. Itu diperbaiki dengan menginstal driver terbaru dari situs realtek