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

32

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:

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/

Geoff Dalgas
źródło
również godne uwagi - używamy również TProxy (przezroczysty serwer proxy) do wysyłania rzeczywistego adresu IP ruchu przychodzącego przez HAProxy. blog.loadbalancer.org/…
Jeff Atwood
LUnix ... heh heh ... hld.c64.org/poldi/lunix/lunix.html
Evan Anderson
2
Nigdy nie ufaj automatycznym ustawieniom w środowisku produkcyjnym. Ustaw prędkość na taką, jaka powinna być i ustaw monitor, aby się upewnić.
Daniel C. Sobral
3
@Daniel Sobral: Muszę z tobą serdecznie się nie zgodzić. W 2003 roku chyba to widziałem. Przy nowoczesnym sprzęcie twarda prędkość portu i dupleks to przepis na uzyskanie niedopasowania prędkości / dupleksu. Autonegocjacja na nowoczesnym sprzęcie Ethernet działa dobrze.
Evan Anderson
1
Stoję z @Danielem Sobralem, zbyt wiele razy miałem awarie sieci spowodowane złymi negocjacjami prędkości w najgorszym momencie, więc na systemach produkcyjnych używam ustawień statycznych. Kiedy tak się dzieje, co mówi stan łącza na przełączniku? Jest zarządzany, prawda? Co mówi system Windows? Postawiłbym na awarię sieci na poziomie łącza, i to właśnie powoduje te niekompletne ARP (nieudane lub czekające na otrzymanie ARP, kto ma). Przyczyną może być zły sprzęt / sterownik. Pozwala zobaczyć, jak idzie po zamianie.
Pablo Alsina

Odpowiedzi:

7

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?


źródło
5

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?

Max Clark
źródło
Jeśli jednak dzieje się to sporadycznie, to sprawia, że ​​myślę, że nie jest to niepoprawnie ustawiona maska ​​podsieci (co, co prawda, często jest przyczyną, że maszyny nie odpowiadają na żądania ARP).
Evan Anderson,
Post wydaje mi się dość jasny. Adres IP .211 to wirtualny adres IP współdzielony przez instancje HAProxy. Adres IP .220 jest przypisany do komputera z systemem Windows, który okresowo traci zdolność komunikowania się z adresem IP .211 (jak widać w wierszu „Interfejs:” wyjścia ARP cytowanym w poście).
Evan Anderson,
196,220 to ip uszkodzonego serwera Windows - 196.211 to wirtualny ip dla interfejsów haproxy.
Geoff Dalgas
4

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).

Evan Anderson
źródło
Gdy wystąpi ten problem, możemy zrestartować uszkodzony serwer WWW (196.220) i będzie on działał - z naszego doświadczenia wynika, że ​​w ciągu 24 godzin ponownie się nie powiedzie.
Geoff Dalgas
1
Interesujące byłoby wiedzieć, czy serwer mógł w ogóle rozmawiać na karcie sieciowej podłączonej do segmentu z maszyną .211 (która, jak rozumiem z waszej aktualizacji, jest teraz zamieniona z segmentem zaplecza). Moje przeczucie mówi, że „bonkers NIC” będzie główną przyczyną tego, ale zobaczymy ...
Evan Anderson
1
Gdy tak się stanie, maszyna na pewno nie można mówić o końcu przednim (publicznego) NIC w ogóle . Karta sieciowa (prywatna) zaplecza pozostaje nienaruszona. Zawsze czułem, że to kierowca NIC szaleje, ale pytanie brzmi „dlaczego”? (także: dzieje się tak z najnowszym sterownikiem Broadcom, a także domyślnym sterownikiem Wink28 R2) Po ponownym uruchomieniu sprawdzę dzienniki zdarzeń, co zajmuje ponad 10 minut, ponieważ najpierw musi zostać wyświetlony niebieski ekran jako część zamknięcia. Wyczyściłem je wcześniej.
Jeff Atwood
angażujemy teraz wsparcie Microsoft, ponieważ szczerze wierzymy, że jest to problem na poziomie systemu operacyjnego. Zrobiliśmy wszystko, co w naszej mocy, aby rozwiązać problemy , i prawdopodobnie wykluczyliśmy ... cóż, wszystko.
Jeff Atwood
Zow. Chciałbym usłyszeć, jak się okazuje.
Evan Anderson
2

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.

Cade Roux
źródło
2

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.

jaredg
źródło
2

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.

Seth
źródło
1

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.
Murali Suriar
źródło
zdecydowanie oglądamy teraz przechwytywanie pakietów
Jeff Atwood
niestety przechwytywanie pakietów nie pokazało nam niczego oczywistego, a maszyna, na której przechwyciliśmy, ma wrażliwy ruch sieciowy, więc nie możemy dać tego ekspertom do obejrzenia.
Jeff Atwood
@Jeff: czy możesz dostarczyć zrzuty pokazujące tylko ruch ARP? Byłbym zainteresowany, aby zobaczyć zachowanie ARP, jeśli nic więcej.
Murali Suriar
postępowaliśmy zgodnie ze wskazówkami pomocy technicznej MSFT w zakresie danych, które chcą przechwycić - zajęło to kilka tygodni, ale w końcu znaleźli dla nas prywatną poprawkę sieci jądra.
Jeff Atwood
0

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.

Chris E.
źródło
0

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

M-Razavi
źródło