Windows Server 2008 R2 ağ bağdaştırıcısının çalışması durdu

TL; DR sürümü: Bunun Windows Server 2008 R2'deki derin bir Broadcom ağ bağlantısı hatası olduğu ortaya çıktı. Intel donanımıyla değiştirmek sorunu çözdü. Artık Broadcom donanımını kullanmıyoruz. Hiç.

Linux-HA projesinden HAProxy'i kalp atışı ile birlikte kullanıyoruz . Yük devretme sağlamak için iki linux örneği kullanıyoruz. Her sunucu IP: 69.59.196.211’de sanal bir arabirim (eth1: 1) kullanılarak paylaşılan kendi IP’lerine ve ikisi arasında paylaşılan tek IP’lerine sahiptir.

Sanal arabirim (eth1: 1) IP 69.59.196.211, arkasındaki windows sunucuları için ağ geçidi olarak yapılandırılmıştır ve trafiği yönlendirmek için ip_forwarding kullanıyoruz.

Windows sunucularımızdan birinde, linux ağ geçitlerimizin arkasında ara sıra ağ kesintisi yaşıyoruz. HAProxy, sunucunun çevrimdışı olduğunu tespit eder; bu, başarısız olan sunucuya geçerek ve ağ geçidini ping yapmaya çalışarak doğrulayabilir:

32 bayt veri ile 69.59.196.211 numaralı ping işlemi:
69.59.196.220 arasında yanıt: Hedef ana bilgisayara erişilemiyor.

arp -aBu başarısız sunucuda çalıştırmak , ağ geçidi adresi için giriş olmadığını gösterir (69.59.196.211):

Arayüz: 69.59.196.220 --- 0xa
İnternet Adresi Fiziksel Adres Türü
69.59.196.161 00-26-88-63-c7-80 dinamik
69.59.196.210 00-15-5d-0a-3e-0e dinamik
69.59.196.212 00-21-5e-4d-45-c9 dinamik
69.59.196.213 00-15-5d-00-b2-0d dinamik
69.59.196.215 00-21-5e-4d-61-1a dinamik
69.59.196.217 00-21-5e-4d-2c-e8 dinamik
69.59.196.219 00-21-5e-4d-38-e5 dinamik
69.59.196.221 00-15-5d-00-b2-0d dinamik
69.59.196.222 00-15-5d-0a-3e-09 dinamik
69.59.196.223 ff-ff-ff-ff-ff-ff statik
224.0.0.22 01-00-5e-00-00-16 statik
224.0.0.252 01-00-5e-00-00-fc statik
225.0.0.1 01-00-5e-00-00-01 statik

Bizim linux ağ geçidinde örnekleri arp -agösterir:

peak1colo-196-220.peak.org (69.59.196.220) eth1 tarihinde <incomplete> adresinde
stackoverflow.com (69.59.196.212) 00: 21: 5e: 4d: 45: c9 [eter] 'de etı1'de
peak-colo-196-215.peak.org (69.59.196.215) 00: 21: 5e: 4d: 61: 1a [eter] 'de et1'de
peak-colo-196-219.peak.org (69.59.196.219) 00: 21: 5e: 4d: 38: e5 [eter] 'de et1'de
peak-colo-196-222.peak.org (69.59.196.222) 00: 15: 5d: 0a: 3e: 09 [eth] 'de
peak-colo-196-209.peak.org (69.59.196.209) 00: 26: 88: 63: c7: 80 [eter] 'de et1'de
peak-colo-196-217.peak.org (69.59.196.217) 00: 21: 5e: 4d: 2c: e8 [eth] 'de

Neden arp bu başarısız sunucunun girişini neden <incomplete> olarak ayarlasın ki? Arp girişlerimizi statik olarak mı tanımlamalıyız? Zamanın% 99'unu çalıştığı için her zaman yalnız bıraktım, ama bu durumda başarısız görünüyor. Bu sorunu çözmek için yardımcı olabileceğimiz başka sorun giderme adımları var mı?

BİZ GERÇEKLERİMİZ

Hala yardım etmeyen linux ağ geçitlerinden birinde test etmek için statik bir arp girişi ekledim.

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

Windows web sunucusunu yeniden başlatmak, ağda başka hiçbir değişiklik yapmadan bu sorunu geçici olarak çözer, ancak deneyimlerimiz bu sorunun geri döneceğini gösterir.

Ağ kartlarını ve anahtarlarını değiştirme

Başarısız olan Windows sunucusunun anahtar bağlantı noktasındaki bağlantı ışığının, başarısız arabirimde 1 GB yerine 100Mb'de çalıştığını fark ettim. Kabloyu diğer birkaç açık porta taşıdım ve bağlantı, denediğim her port için 100Mb gösteriyor. Ayrıca kabloyu da aynı şekilde değiştirdim. Ağ kartının özelliklerini pencerelerde değiştirmeyi denedim ve sunucu kilitlendi ve uygulamanın tıklatılmasından sonra donanımın sıfırlanması gerekiyordu. Bu Windows sunucusunda iki fiziksel ağ arayüzü var, bu yüzden sorunun arayüzde olup olmadığını görmek için iki arayüzde kabloları ve ağ ayarlarını değiştirdim. Genel arayüz tekrar kapanırsa, bunun ağ kartıyla ilgili bir sorun olmadığını anlayacağız.

(Ayrıca elimizde olan başka bir anahtar denedik, değişiklik yok)

Ağ donanım sürücüsü sürümlerini değiştirme

En son Broadcom sürücüsünün yanı sıra Windows Server 2008 R2 ile birlikte gelen yerleşik sürücüyle de aynı sorunu yaşadık.

Ağ kablolarını değiştirme

Son bir çaba olarak, gerçekleşen başka bir değişikliğin sunucularımız / anahtarımız arasındaki tüm bağlantı kablolarının değiştirilmesi olduğunu hatırladık. Özel arayüzler için 1 ft - 3 ft yeşil uzunlukta ve genel arayüzler için kırmızı kablo seti olmak üzere iki set satın aldık. Tüm ortak arabirim patch kablolarını farklı bir marka ile değiştirdik ve sunucularımızı tam bir hafta sorunsuzca çalıştırdık ... aaaaave sonra sorun tekrar çözüldü.

Sağlama toplamı devre dışı bırak, TProxy'yi kaldır

Ayrıca sürücüdeki TCP / IP sağlama toplamı devre dışı bırakmayı da devre dışı bırakmayı denedik. Şimdi TProxy'yi çıkarıyoruz ve x-forwarded-forherhangi bir fantezi IP adresi yeniden yazmadan daha geleneksel bir ağ düzenlemesine geçiyoruz . Bunun yardımcı olup olmadığını göreceğiz.

Sanallaştırma sağlayıcılarını değiştir

Şans eseri bu, Hyper-V ile bir şekilde ilişkiliydi (üzerinde Linux VM'leri barındırıyoruz), VMWare Sunucusuna geçtik. Değişiklik yok.

Ana bilgisayar modelini değiştir

Sorun giderme ipimizin sonuna ulaştık ve şimdi resmen Microsoft desteğini içeriyoruz. Ana bilgisayar modelini değiştirmeyi tavsiye ettiler:

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

Bunu yaptık ve muhtemelen 2008 R2 SP1’de yayınlanmış olan yayınlanmamış çekirdek düzeltmelerini de aldık. Düzeltme yok.

Ağ kartı donanımını değiştirme

Sonuçta, Broadcom ağ donanımını Intel ağ donanımıyla değiştirmek bizim için bu sorunu çözdü. Bu yüzden Broadcom Windows Server 2008 R2 sürücülerinin hatalı olduğunu düşünmeye meyilliyim!

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

Gönderen http://linux-ip.net/html/ether-arp.html :

Talep edilen bir hedef IP için ARP önbellek girişi mevcut değilse, çekirdek bir cevap alana kadar mcast_solicit ARP talepleri üretecektir. Bu keşif süresi boyunca, ARP önbellek girişi tamamlanmamış bir durumda listelenir. Arama, belirtilen sayıda ARP isteğinden sonra başarılı olmazsa, ARP önbellek girişi başarısız durumda listelenir. Arama başarılı olursa, çekirdek yanıtı ARP önbelleğine girer ve onay ve güncelleme zamanlayıcılarını sıfırlar.

Ağ geçidi kutunuz, ARP isteklerine ağ geçidi kutunuzdan yanıt vermiyor (veya çok yavaş yanıt veriyor gibi). Bu <incomplete>sonunda geçer <failed>mi? Sunucu ile ağ geçidi arasında hangi ağ donanımına sahipsiniz? ARP isteklerinin iki ana bilgisayar arasında bir yerde filtrelenmesi veya engellenmesi mümkün mü?

Bu, adresi attığınız anlamına gelir; IP, bir PTR kaydına (dolayısıyla adı) sahiptir, ancak söz konusu makineden hiçbir şey yanıt vermedi. Bunu gördüğümüzde, genellikle alt küme maskesinin yanlış ayarlanmasından kaynaklanır - veya IP'lerin yanlışlıkla bunun yerine eth arabirimine bağlanmış bir geridöngü arabirimine bağlı olması durumunda.

196.220 nedir? 196.211 ile ilişkisi nedir? .202'nin HA Proxy sunucusundan biri olduğunu farz ediyorum. İfconfig -a & arp -a komutunu çalıştırdığınızda ne gösterir?

Max Clark'ın dediği gibi, <incomplete> sadece 69.59.196.211'in 69.59.196.220 için ARP talebinde bulunduğu ve henüz bir yanıt almadığı anlamına gelir. (Windows-ülkesinde bunu "00-00-00-00-00-00" ile eşleştiren ARP eşlemesi olarak göreceksiniz ... Bana öyle tuhaf geliyor ki BTW, böyle bir ARP eşlemesi görmüyorsunuz. 69.59.196.220 için 69.59.196.220.)

Statik ARP girişlerini kullanmaktan hoşlanmıyorum çünkü deneyimlerime göre ARP genellikle her zaman işini yapıyor.

Ben olsaydım, "başarısız" Windows makinesine (69.59.196.220) uygun Ethernet arabirimini tarardım ve 69.59.196.211 için ARP'yi gözlemlemek ve 69.59'dan ARP taleplerine nasıl cevap verip vermediğini gözlemlemek için. 196,211. tcpdump -i interface-name arpARP trafiğinin Linux makinesinin yanından nasıl göründüğünü görmek için yalnızca ARP için ağ geçidi makinesinde koklamayı da düşünürdüm .

Ben gelen, biliyorum blogda bir arka uç ağ ve bir ön uç ağı aldığına göre,. Bu kesintiler sırasında, "başarısız" Windows sunucusunun (69.59.196.220) ön uç ağdaki diğer makinelerle iletişim kurmasında herhangi bir sorun var mı, yoksa sadece ağ geçidiyle konuşmada sorun mu yaşıyor? Hareket halindeyken yakalayan makineye ön uç veya arka uç ağ üzerinden geliyorsanız merak ediyorum.

Oluştuğunda sorunu "çözmek" için ne yapıyorsunuz?

Düzenle:

Güncellemenizden, sorunu çözmek için "başarısız" Windows makinesini yeniden başlattığınızı görüyorum. Bunu bir dahaki sefere yapmadan önce, Windows makinesinin ön uç arayüzünde "konuşabileceğini" söyleyebilir misiniz? Ayrıca, route printbaşarısızlık sırasında da yönlendirme tablosunun bir kopyasını Windows makinesinden ( ) alın. (NIC / sürücüsünün Windows makinede zor durumda olup olmadığına karar vermeye çalışıyorum.)

Bu belge farklı durumları göstermektedir (Tablo 2.1). Eksik, ilk ARP talebini gönderdiği anlamına gelir (muhtemelen eski, gecikmeli, sondadan sonra) ancak henüz bir cevap alamadı.

Haproxy düğümündeki statik ARP'nin yardım etmemesinin nedeni, web sunucunuzun hala ağ geçidine nasıl geri döneceğinizi çözememesidir.

Web sunucusundaki Statik ARP, web sunucularınızın haproxy düğümlerinden biri arızalandığında ağ geçitlerini değiştirme yeteneğini ortadan kaldırır - Sanal arabirimin haproxy düğümünün eth1 ile aynı MAC adresini paylaştığını tahmin ediyorum, bu nedenle Her web sunucusuna iki ağ geçidinden birine kod verin.

Arızalı web sunucusunda kurulu herhangi bir güvenlik yazılımı var mı? Üzerinde Symantec Endpoint Security yazılımı olan bir Windows 2008 sunucusuyla uzun bir gece geçirdim - ağ geçidinin ARP paketlerini görmesini engelleyen bir yığın filtreleme kodu yüklüyor. Bunun için düzeltme (Microsoft tarafından sağlanan), DLL'i yükleyen kayıt defteri girdisini kaldırmaktı.

Bu sorun oluştuğunda, ağ bağdaştırıcısının tümünün aygıt yöneticisinden kaldırılması ve yeniden yüklenmesi yardımcı olmuş gibi göründü.

Arp girişinizi statik olarak ayarladığınızdan, sunucularınız ağ geçidini nerede bulacağını bilir . Ancak, anahtarınız ağ geçidinin nerede olduğunu bilmiyorsa, paketlerinizi iletmez.

HAproxy'niz ve web sunucularınız arasında kötü (veya karışık) bir geçiş varmış gibi görünüyor. Yeniden başlat.

Ya bu, ya da HAproxy sunucularınız hangisinin kontrol altında olduğu konusunda hemfikir değil ve her ikisi de .211 için arp aramalarına cevap veriyor.

Aynı hatlar boyunca, anahtarınız aşırı yüklenirse, HAproxy sunucularınız birbirleriyle yeterince hızlı iletişim kuramayabilir ve arızalanabilir.

Bu sorun bir daha ortaya çıktığında, her birinin hangi ARP trafiğini gözlemlediğini belirlemek için söz konusu iki ana bilgisayarda bazı paket yakalamaları çalıştırmanızı öneririm.

HAproxy makineniz büyük olasılıkla yüklü tcpdump tadında olacaktır . Windows makinesi için Wireshark veya Microsoft Network Monitor gibi bir WinPCAP uygulamasına ihtiyacınız olacak .

Aslında, sorun özellikle ARP ile birlikte göründüğü gibi, yalnızca tüm ARP trafiğini HAproxy makinesinde ve Windows makinesinde söz konusu Windows makinesinde (argüman uğruna) 10 MB'lik bir yakalama yakalama dosyasıyla sürekli olarak kaydedebilirsiniz. Bu, bir arıza tespit ettiğinizde, yakalama dosyasında, arızadan önceki ARP trafiğini içerecek şekilde yeterince büyük olmalıdır. (Ne kadar veri ürettiğini görmek için yakalamayı bir saat kadar çalıştırarak denemeye değer).

Linux tcpdump için örnek yakalama sözdizimi (not, bunu test etmek için kullanışlı bir Linux kutum yok; lütfen üretimde kullanmadan önce -C ve -W davranışını test edin!):

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

Bu umarım size tam olarak neyin başarısız olduğuna dair bir fikir verecektir. Bir ARP girişinin süresi dolduğunda (ve bu makaleye göre , Windows'un yeni sürümleri 'etkin olmayan' girişleri çok saldırganlaştırıyor gibi görünmektedir), aşağıdakilerin olmasını beklerdim:

1. Kaynak ana bilgisayar, hedef ana bilgisayara bir ARP isteği gönderir. ARP istekleri genellikle yayınlanır, ancak bir ana bilgisayarın varolan bir girişi yeniliyor olması durumunda, ARP'ye tek noktaya yayın gönderilebilir.
2. Hedef ana bilgisayar bir ARP yanıtıyla cevap verecektir. Zamanın% 99'u bu tek noktaya yayın olacak, ancak RFC yayın yanıtlarına izin veriyor. (Daha fazla ayrıntı için ayrıca bkz. IPv4 Adres Çarpışma Tespiti ile ilgili RFC ).

Kulağa geldiği kadar basit, bu sürece müdahale edebilecek başka birçok şey var:

• Orijinal istek hedefe ulaşmıyor olabilir.
• İstek hedefe ulaşıyor olabilir, ancak cevap kaynağa ulaşmıyor olabilir.
• Bir çeşit yüksek kullanılabilirlik mekanizması, ARP'nin 'normal' davranışına müdahale ediyor olabilir:
  • HAProxy düğümleri arasındaki yük devretme nasıl çalışır? Paylaşılan bir MAC adresi kullanıyor mu, yoksa düğümler arasında bir IP adresi veremiyorsa, ARP'yi kullanıyor mu?
  • Yukarıdaki ARP tablolarındaki MAC adreslerinin çoğu, görünüşe göre Microsoft'a kayıtlı olan 00-15-5D ile başlar. Söz konusu Windows makinesinde herhangi bir kümeleme veya başka bir HA kullanıyor musunuz? Bu 00-15-5D MAC adresleri, Windows sunucusunda bir 'ipconfig / all' yaparken donanım NIC'leriyle ilişkilendirdiğinizle aynı mı?

Bunun tekrar / ne zaman olacağını kontrol etmek için gerekenler:

• ARP trafiğinin paket yakalamalarına bakın; konuşmanın herhangi bir kısmı açık bir şekilde gerçekleşmedi mi?
• Anahtarın köprü / CAM tablolarını kontrol edin; Söz konusu tüm MAC adresleri, beklediğiniz portlarla nasıl eşleşir?
• Alt ağdaki diğer ana bilgisayarlar, hem Windows hem de HAProxy ana bilgisayarlarının IP adresleri için geçerli ARP girişlerine sahip mi?
• Birden fazla farklı kaynak makinede aynı hedef IP için ARP girişleri aynı MAC adresine mi çözümleniyor? yani, alt ağdaki birkaç ana bilgisayara oturum açın ve 196.211'in her ikisinde de aynı MAC adresine çözümlendiğini doğrulayın.

NIC'deki tüm trafiğin durduğu, ancak bağlantıda kalacağı ve NIC LED'lerinin iletişim göstereceği 2008 R2 terminal sunucularımızdan biriyle de benzer bir sorun yaşadık. Bu, haftada 2-3 kez kırpmaya devam eden, ancak 12-13 saat kadar çalıştıktan sonra (sunucu her gece yeniden başlatılıyor) devam eden bir sorundu.

NetbalancerService hizmetini sonlandırmayı (meraktan) denemenin ardından Seriousbit Netbalancer'ın nedeni olduğunu gördüm. Trafik daha sonra arayüz boyunca hareket etmeye başladı. O zamandan beri Netbalancer'ı kaldırdım.

Asus Mainboard lan ile aynı sorunu yaşadım. Realtek web sitesinden en yeni bir sürücü yüklenerek giderildi