Karta sieciowa systemu Windows Server 2008 R2 przestaje działać, wymaga twardego ponownego uruchomienia

Wersja TL; DR: Okazuje się, że był to głęboki błąd sieci Broadcom w Windows Server 2008 R2. Zastąpienie sprzętem Intel naprawiło to. Nie używamy już sprzętu Broadcom. Zawsze.

Używamy HAProxy wraz z pulsu z projektu Linux-HA. Używamy dwóch instancji Linuksa, aby zapewnić przełączenie awaryjne. Każdy serwer ma własny publiczny adres IP i pojedynczy adres IP, który jest dzielony między nimi za pomocą interfejsu wirtualnego (eth1: 1) pod adresem IP: 69.59.196.211

Interfejs wirtualny (eth1: 1) IP 69.59.196.211 jest skonfigurowany jako brama dla serwerów Windows za nimi i używamy ip_forwarding do kierowania ruchem.

Od czasu do czasu mamy do czynienia z awarią sieci na jednym z naszych serwerów Windows za bramami Linuksa. HAProxy wykryje, że serwer jest w trybie offline, co możemy zweryfikować, przesyłając go na uszkodzony serwer i próbując wysłać polecenie ping do bramy

Pinging 69.59.196.211 z 32 bajtami danych:
Odpowiedź od 69.59.196.220: Host docelowy jest nieosiągalny.

Uruchomienie arp -ana tym uszkodzonym serwerze pokazuje, że nie ma wpisu adresu bramy (69.59.196.211):

Interfejs: 69.59.196.220 --- 0xa
Typ adresu fizycznego adresu internetowego
69.59.196.161 00-26-88-63-c7-80 dynamiczny
69.59.196.210 00-15-5d-0a-3e-0e dynamiczny
69.59.196.212 00-21-5e-4d-45-c9 dynamic
69.59.196.213 00-15-5d-00-b2-0d dynamiczny
69.59.196.215 00-21-5e-4d-61-1a dynamiczny
69.59.196.217 00-21-5e-4d-2c-e8 dynamiczny
69.59.196.219 00-21-5e-4d-38-e5 dynamiczny
69.59.196.221 00-15-5d-00-b2-0d dynamiczny
69.59.196.222 00-15-5d-0a-3e-09 dynamiczny
69.59.196.223 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 statyczny
224.0.0.252 01-00-5e-00-00-fc statyczny
225.0.0.1 01-00-5e-00-00-01 statyczny

Na naszych instancjach bramy linux arp -apokazuje:

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

Dlaczego arp czasami ustawia wpis dla tego serwera, który uległ awarii, jako <kompletny>? Czy powinniśmy definiować nasze wpisy arp statycznie? Zawsze zostawiałem arp w spokoju, ponieważ działa 99% czasu, ale w tym jednym przypadku wydaje się, że zawodzi. Czy są jakieś dodatkowe kroki rozwiązywania problemów, które możemy podjąć, aby rozwiązać ten problem?

Rzeczy, które próbowaliśmy

Dodałem statyczny wpis arp do testowania na jednej z bram Linuksa, co wciąż nie pomogło.

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

Ponowne uruchomienie serwera systemu Windows tymczasowo rozwiązuje ten problem bez żadnych innych zmian w sieci, ale z naszego doświadczenia wynika, że ​​problem ten powróci.

Zamiana kart sieciowych i przełączników

Zauważyłem, że lampka łącza na porcie przełącznika dla uszkodzonego serwera Windows działała z prędkością 100 Mb zamiast 1 Gb na uszkodzonym interfejsie. Przeniosłem kabel do kilku innych otwartych portów, a łącze wskazało 100 Mb dla każdego portu, którego próbowałem. Zamieniłem też kabel z tym samym rezultatem. Próbowałem zmienić właściwości karty sieciowej w systemie Windows, a serwer został zamknięty i wymagałem twardego resetu po kliknięciu przycisku Zastosuj. Ten serwer Windows ma dwa fizyczne interfejsy sieciowe, więc zamieniłem kable i ustawienia sieciowe na dwóch interfejsach, aby sprawdzić, czy problem występuje po interfejsie. Jeśli interfejs publiczny ponownie się zawiesi, będziemy wiedzieć, że nie jest to problem z kartą sieciową.

(Wypróbowaliśmy też inny przełącznik, który mamy pod ręką, bez zmian)

Zmiana wersji sterowników sprzętu sieciowego

Mamy ten sam problem z najnowszym sterownikiem Broadcom, a także z wbudowanym sterownikiem, który jest dostarczany z systemem Windows Server 2008 R2.

Wymiana kabli sieciowych

Jako ostatni wysiłek przywołaliśmy kolejną zmianę, która nastąpiła, to wymiana wszystkich kabli połączeniowych między naszymi serwerami / przełącznikami. Kupiliśmy dwa zestawy, jeden zielony o długości 1 stopy - 3 stopy dla interfejsów prywatnych i drugi zestaw czerwonych kabli dla interfejsów publicznych. Wymieniliśmy wszystkie kable z interfejsem publicznym innej marki i przez cały tydzień bez problemu prowadziliśmy nasze serwery ... aaaaaa, a potem problem się powtórzył.

Wyłącz odciążanie sumy kontrolnej, usuń TProxy

Próbowaliśmy również wyłączyć odciążanie sumy kontrolnej TCP / IP w sterowniku, bez zmian. Wyciągamy teraz TProxy i przechodzimy do bardziej tradycyjnego x-forwarded-forukładu sieci bez żadnego fantazyjnego przepisywania adresu IP. Zobaczymy, czy to pomoże.

Przełącz dostawców wirtualizacji

Przy okazji było to w jakiś sposób związane z Hyper-V (obsługujemy na nim maszyny wirtualne z systemem Linux), przeszliśmy na serwer VMWare. Brak zmiany.

Zmień model hosta

Dotarliśmy do końca naszej liny do rozwiązywania problemów i teraz formalnie angażujemy wsparcie Microsoft. Zalecili zmianę modelu hosta:

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

Zrobiliśmy to, a także otrzymaliśmy kilka niepublikowanych poprawek jądra, które prawdopodobnie zostały wprowadzone do wersji R2 z dodatkiem SP1 2008. Bez naprawy.

Wymiana sprzętu karty sieciowej

Ostatecznie zastąpienie sprzętu sieciowego Broadcom sprzętem sieciowym Intel rozwiązało ten problem. Dlatego jestem skłonny myśleć, że to wina sterowników Broadcom Windows Server 2008 R2!

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

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

Jeśli nie ma wpisu pamięci podręcznej ARP dla żądanego docelowego adresu IP, jądro będzie generowało żądania ARP mcast_solicit aż do otrzymania odpowiedzi. W tym okresie wykrywania pozycja pamięci podręcznej ARP będzie wyświetlana w stanie niepełnym. Jeśli wyszukiwanie nie powiedzie się po określonej liczbie żądań ARP, pozycja pamięci podręcznej ARP zostanie wyświetlona w stanie niepowodzenia. Jeśli wyszukiwanie się powiedzie, jądro wprowadza odpowiedź do pamięci podręcznej ARP i resetuje liczniki potwierdzenia i aktualizacji.

Wygląda na to, że twoje pole bramy nie odpowiada (lub odpowiada zbyt wolno) na żądania ARP z twojego pola bramy. Czy to <incomplete>ostatecznie się zmienia <failed>? Jaki masz sprzęt sieciowy między serwerem a bramą? Czy jest możliwe, że rozsyłane żądania ARP są filtrowane lub blokowane gdzieś między dwoma hostami?

Oznacza to, że wysłałeś polecenie ping do adresu, adres IP ma rekord PTR (stąd nazwa), ale nic nie odpowiedziała na danym komputerze. Kiedy to widzimy, najczęściej dzieje się tak z powodu nieprawidłowego ustawienia maski podsieci lub w przypadku adresów IP powiązanych z interfejsem pętli zwrotnej, które przypadkowo zostały powiązane z interfejsem eth.

Co to jest 196,220? Jaki jest związek z 196.211? Zakładam, że .220 jest jednym z hostów serwera proxy HA. Kiedy uruchomisz na nim ifconfig -a & arp -a, co to pokazuje?

Jak mówi Max Clark, <komplet> oznacza po prostu, że 69.59.196.211 wysłało żądanie ARP dla 69.59.196.220 i jeszcze nie otrzymało odpowiedzi. (W Windows-land zobaczysz to jako mapowanie ARP na „00-00-00-00-00-00” ... BTW wydaje mi się dziwne, że nie widzisz takiego mapowania ARP na 69.59.196.220 dla 69.59.196.211.)

Nie lubię używać statycznych wpisów ARP, ponieważ z mojego doświadczenia wynika, że ​​ARP generalnie wykonuje swoją pracę przez cały czas.

Gdybym to był ja, wąchałbym odpowiedni interfejs Ethernet na „niedziałającym” komputerze z systemem Windows (69.59.196.220), aby obserwować ARP dla 69.59.196.211 i obserwować, jak / jeśli odpowiada na żądania ARP z 69.59. 196,211. Zastanowiłbym się również nad sniffowaniem na maszynie bramy tylko dla ARP ( tcpdump -i interface-name arp), aby zobaczyć, jak wygląda ruch ARP z boku maszyny z systemem Linux.

Wiem z bloga , że masz sieć zaplecza i sieć front-end. Czy podczas tych awarii serwer Windows z błędem (69.59.196.220) ma jakieś problemy z komunikacją z innymi komputerami w sieci front-end, czy może po prostu ma problemy z komunikacją z bramą? Jestem ciekawy, czy wchodzisz w awarię komputera przez sieć front-end lub back-end, gdy łapiesz go na gorącym uczynku.

Co robisz, aby „rozwiązać” problem, gdy się pojawi?

Edytować:

Z aktualizacji wynika, że ​​ponownie uruchamiasz „nieudany” komputer z systemem Windows, aby rozwiązać problem. Czy zanim to zrobisz następnym razem, czy możesz sprawdzić, czy komputer z systemem Windows może w ogóle „rozmawiać” na interfejsie użytkownika? Weź także kopię tabeli routingu z komputera z systemem Windows ( route print) również podczas awarii. (Zasadniczo próbuję ustalić, czy karta sieciowa / sterownik nie działa prawidłowo na komputerze z systemem Windows).

Ten dokument pokazuje różne stany (tabela 2.1). Niekompletne oznaczałoby, że wysłał pierwsze żądanie ARP (prawdopodobnie po przestarzałej, opóźnionej, sondującej), ale jeszcze nie otrzymał odpowiedzi.

Powodem, dla którego statyczny ARP w węźle haproxy nie pomaga, jest to, że twój serwer WWW nadal nie może znaleźć sposobu na powrót do bramy.

Statyczny ARP na serwerze internetowym przerywa zdolność serwerów do przełączania bram, gdy jeden z węzłów haproxy ulegnie awarii - Zgaduję, że interfejs wirtualny ma ten sam adres MAC, co w et1 węzła haproxy, więc musicie kod do jednej z dwóch bram do każdego serwera WWW.

Czy masz oprogramowanie zabezpieczające zainstalowane na uszkodzonym serwerze WWW? Spędziłem długą noc z serwerem Windows 2008, na którym był Symantec Endpoint Security - instaluje trochę kodu filtrującego na stosie sieciowym, który w ogóle nie pozwala na zobaczenie pakietów ARP bramy. Rozwiązaniem tego problemu (podanym przez Microsoft) było usunięcie wpisu rejestru, który załadował bibliotekę DLL.

Innym razem, gdy wystąpił ten problem, usunięcie całej karty sieciowej z menedżera urządzeń i ponowna instalacja wydawały się pomocne.

Ponieważ statycznie ustawiłeś wpis arp, twoje serwery wiedzą, gdzie znaleźć bramę. Jeśli jednak przełącznik nie wie, gdzie jest brama, nie przekaże pakietów.

Wygląda na to, że masz złe (lub zdezorientowane) przełączanie między HAproxy i serwerami internetowymi. Uruchom ponownie.

Albo to, albo twoje serwery HAproxy nie zgadzają się co do tego, który z nich ma kontrolę, i oba odpowiadają na zapytania arp dla .211.

Na tych samych liniach, jeśli twój przełącznik jest przeciążony, twoje HAproxies mogą nie być w stanie komunikować się ze sobą wystarczająco szybko i ulegają awarii.

Następnym razem, gdy wystąpi ten problem, sugeruję uruchomienie przechwytywania pakietów na dwóch przedmiotowych hostach, aby ustalić, jaki ruch ARP obserwuje każdy z nich.

Twoja maszyna HAproxy najprawdopodobniej będzie miała zainstalowany smak tcpdump . W przypadku komputera z systemem Windows potrzebujesz aplikacji WinPCAP , takiej jak Wireshark lub Microsoft Network Monitor .

W rzeczywistości, myśląc o tym, ponieważ wydaje się, że problem dotyczy konkretnie ARP, możesz potencjalnie po prostu stale rejestrować cały ruch ARP na maszynie HAproxy i maszynie Windows, o której mowa, z kroczącym plikiem przechwytywania (na wszelki wypadek) 10 MB. Powinno to być wystarczająco duże, aby do czasu wykrycia awarii plik przechwytywania nadal zawierał ruch ARP sprzed awarii. (Warto eksperymentować, uruchamiając przechwytywanie przez około godzinę, aby zobaczyć, ile danych generuje).

Przykładowa składnia przechwytywania dla Linux tcpdump (uwaga: nie mam pod ręką Linux-a do przetestowania tego; proszę przetestować zachowanie -C i -W przed użyciem w produkcji!):

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

Mam nadzieję, że powinno to dać ci pewne wskazówki, co dokładnie zawodzi. Po wygaśnięciu wpisu ARP (i zgodnie z tym artykułem nowsze wersje systemu Windows wydają się bardzo agresywnie starzeć „nieaktywne” wpisy), spodziewałbym się, że tak się stanie:

1. Host źródłowy wyśle ​​żądanie ARP do hosta docelowego. Żądania ARP są generalnie rozgłaszane, ale w przypadku, gdy host odświeża istniejący wpis, ARP może zostać wysłany w trybie emisji pojedynczej.
2. Host docelowy odpowie odpowiedzią ARP. W 99% przypadków będzie to transmisja pojedyncza, ale RFC zezwala na odpowiedzi rozgłoszeniowe. (Więcej informacji znajduje się w dokumencie RFC dotyczącym wykrywania kolizji adresów IPv4 ).

Choć wydaje się to proste, istnieje wiele innych rzeczy, które mogą zakłócać ten proces:

• Pierwotne żądanie może nie dotrzeć do celu.
• Żądanie może docierać do celu, ale odpowiedź może nie docierać do źródła.
• Jakiś mechanizm wysokiej dostępności może zakłócać „normalne” zachowanie ARP:
  • Jak działa przełączanie awaryjne między węzłami HAProxy? Czy używa współdzielonego adresu MAC, czy też korzysta z nieodpłatnego ARP, aby zawodzić adres IP między węzłami?
  • Wiele adresów MAC w powyższych tabelach ARP zaczyna się od 00-15-5D, który najwyraźniej jest zarejestrowany w firmie Microsoft. Czy korzystasz z jakiejkolwiek formy klastrowania lub innej wysokiej dostępności na danym komputerze z systemem Windows? Czy te adresy MAC 00-15-5D są tymi samymi adresami, które widzisz związane ze sprzętowymi kartami sieciowymi podczas wykonywania polecenia ipconfig / all na serwerze Windows?

Rzeczy, aby sprawdzić, czy / kiedy to się powtórzy:

• Spójrz na przechwytywanie pakietów ruchu ARP; czy jakakolwiek część rozmowy najwyraźniej nie miała miejsca?
• Sprawdź tabele mostkowania / CAM przełącznika; czy wszystkie omawiane adresy MAC są odwzorowane na porty, których oczekujesz?
• Czy inne hosty w podsieci mają prawidłowe wpisy ARP dla adresów IP hostów Windows i HAProxy?
• Czy wpisy ARP dla tego samego docelowego adresu IP na wielu różnych komputerach źródłowych są przetwarzane na ten sam adres MAC? tj. zaloguj się do kilku innych hostów w podsieci i sprawdź, czy 196.211 rozpoznaje ten sam adres MAC w obu.

Wystąpił podobny problem z jednym z naszych serwerów terminali R2 w 2008 r., W którym cały ruch na karcie sieciowej zostałby zatrzymany, ale pozostałby podłączony, a diody LED karty sieciowej pokazywałyby komunikaty. To był ciągły problem, który pojawiał się 2-3 razy w tygodniu, ale dopiero po około 12-13 godzinach bezczynności (serwer jest restartowany co noc).

Odkryłem, że przyczyną był Seriousbit Netbalancer po tym, jak spróbowałem (z ciekawości) zakończyć usługę NetbalancerService. Następnie ruch zaczął się przesuwać przez interfejs. Od tego czasu odinstalowałem Netbalancer.

Miałem ten sam problem z siecią Asus na płycie głównej. Zostało to naprawione poprzez zainstalowanie najnowszego sterownika ze strony Realtek