Windows Server 2008 R2 네트워크 어댑터가 작동을 멈추고 하드 재부팅이 필요합니다

TL; DR 버전 : Windows Server 2008 R2의 심층적 인 Broadcom 네트워킹 버그였습니다. 인텔 하드웨어로 교체하여 수정했습니다. 더 이상 Broadcom 하드웨어를 사용하지 않습니다. 이제까지.

우리는 Linux-HA 프로젝트의 하트 비트 와 함께 HAProxy 를 사용하고 있습니다 . 장애 조치를 제공하기 위해 두 개의 Linux 인스턴스를 사용하고 있습니다. 각 서버에는 고유 한 공용 IP와 IP의 가상 인터페이스 (eth1 : 1)를 사용하여 두 서버간에 공유되는 단일 IP가 있습니다 : 69.59.196.211

가상 인터페이스 (eth1 : 1) IP 69.59.196.211은 그 뒤에있는 Windows 서버의 게이트웨이로 구성되며 ip_forwarding을 사용하여 트래픽을 라우팅합니다.

Linux 게이트웨이 뒤의 Windows 서버 중 하나에서 가끔 네트워크 중단이 발생했습니다. HAProxy는 서버가 오프라인 상태임을 감지하여 실패한 서버로 이동하고 게이트웨이를 핑 (Ping)하여 확인할 수 있습니다.

32 바이트의 데이터로 핑 69.59.196.211 :
69.59.196.220의 응답 : 대상 호스트에 연결할 수 없습니다.

arp -a이 실패한 서버에서 실행 하면 게이트웨이 주소 (69.59.196.211)에 대한 항목이 없음을 나타냅니다 .

인터페이스 : 69.59.196.220 --- 0xa
인터넷 주소 실제 주소 유형
69.59.196.161 00-26-88-63-c7-80 동적
69.59.196.210 00-15-5d-0a-3e-0e 동적
69.59.196.212 00-21-5e-4d-45-c9 동적
69.59.196.213 00-15-5d-00-b2-0d 동적
69.59.196.215 00-21-5e-4d-61-1a 동적
69.59.196.217 00-21-5e-4d-2c-e8 동적
69.59.196.219 00-21-5e-4d-38-e5 동적
69.59.196.221 00-15-5d-00-b2-0d 동적
69.59.196.222 00-15-5d-0a-3e-09 동적
69.59.196.223 ff-ff-ff-ff-ff-ff 정적
224.0.0.22 01-00-5e-00-00-16 정적
224.0.0.252 01-00-5e-00-00-fc 정적
225.0.0.1 01-00-5e-00-00-01 정적

Linux 게이트웨이 인스턴스에서 다음을 arp -a보여줍니다.

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

arp가 때때로이 실패한 서버의 항목을 <불완전>으로 설정 한 이유는 무엇입니까? arp 항목을 정적으로 정의해야합니까? 99 %의 시간 동안 작동하기 때문에 항상 arp를 내버려 두었지만이 경우에는 실패한 것으로 보입니다. 이 문제를 해결하는 데 도움이되는 추가 문제 해결 단계가 있습니까?

우리가 시도한 것들

여전히 도움이되지 않은 Linux 게이트웨이 중 하나에서 테스트하기 위해 정적 arp 항목을 추가했습니다.

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 웹 서버를 재부팅하면 다른 네트워크 변경없이이 문제가 일시적으로 해결되지만 경험상이 문제가 다시 발생합니다.

네트워크 카드 및 스위치 교환

실패한 Windows 서버의 스위치 포트에있는 링크 표시등이 실패한 인터페이스의 1Gb 대신 100Mb에서 실행되고 있음을 알았습니다. 케이블을 다른 여러 열린 포트로 옮겼으며 링크는 내가 시도한 각 포트에 100Mb를 표시했습니다. 또한 동일한 결과로 케이블을 교체했습니다. Windows에서 네트워크 카드의 속성을 변경하려고 시도했지만 서버가 잠기고 적용을 클릭 한 후 하드 리셋이 필요했습니다. 이 Windows 서버에는 두 개의 물리적 네트워크 인터페이스가 있으므로 두 인터페이스의 케이블과 네트워크 설정을 교체하여 문제가 인터페이스를 따르는 지 확인했습니다. 공용 인터페이스가 다시 다운되면 네트워크 카드에 문제가 없음을 알게됩니다.

(우리는 또한 다른 스위치를 시도했지만 변경하지 않았습니다)

네트워크 하드웨어 드라이버 버전 변경

최신 Broadcom 드라이버와 Windows Server 2008 R2에 포함 된 기본 제공 드라이버와 동일한 문제가있었습니다.

네트워크 케이블 교체

마지막 도랑 노력으로 우리는 서버 / 스위치 사이의 모든 패치 코드를 교체한다는 또 다른 변화를 기억했습니다. 개인 인터페이스의 경우 1ft-3ft 길이의 녹색과 공용 인터페이스의 다른 빨간색 케이블 세트 두 개를 구입했습니다. 우리는 모든 공용 인터페이스 패치 케이블을 다른 브랜드로 교체하고 일주일 동안 문제없이 서버를 운영했습니다 ...

체크섬 오프로드 비활성화, TProxy 제거

또한 드라이버에서 TCP / IP 체크섬 오프로드를 비활성화하고 변경하지 않았습니다. 우리는 이제 TProxy를 끌어 내고 x-forwarded-for멋진 IP 주소를 다시 쓰지 않고도 보다 전통적인 네트워크 구성으로 전환하고 있습니다. 도움이되는지 살펴 보겠습니다.

스위치 가상화 공급자

오프-가능성에 이것은 Hyper-V와 관련이 있었으며 (우리는 Linux VM을 호스트하고 있음) VMWare Server로 전환했습니다. 변경 없음.

호스트 모델 전환

문제 해결 과정이 끝났고 이제 공식적으로 Microsoft 지원이 필요합니다. 호스트 모델 변경을 권장했습니다.

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

우리는 그렇게했으며 2008 R2 SP1에 포함 된 일부 미공개 커널 핫픽스도 얻었습니다. 수정 사항이 없습니다.

네트워크 카드 하드웨어 교체

궁극적으로 Broadcom 네트워크 하드웨어를 Intel 네트워크 하드웨어로 교체하면이 문제가 해결되었습니다. 따라서 Broadcom Windows Server 2008 R2 드라이버에 결함이 있다고 생각합니다.

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

에서 http://linux-ip.net/html/ether-arp.html :

요청 된 대상 IP에 대한 ARP 캐시 항목이 없으면 커널은 응답을받을 때까지 mcast_solicit ARP 요청을 생성합니다. 이 발견 기간 동안 ARP 캐시 항목은 불완전한 상태로 나열됩니다. 지정된 수의 ARP 요청 후에 조회에 실패하면 ARP 캐시 항목이 실패한 상태로 나열됩니다. 조회가 성공하면 커널은 ARP 캐시에 응답을 입력하고 확인 및 업데이트 타이머를 재설정합니다.

게이트웨이 상자가 게이트웨이 상자의 ARP 요청에 응답하지 않거나 너무 느리게 응답하는 것 같습니다. 그 않습니다 <incomplete>결국 전환 <failed>? 서버와 게이트웨이 사이에 어떤 네트워크 하드웨어가 있습니까? 브로드 캐스트 ARP 요청이 두 호스트 사이에서 필터링되거나 차단 될 수 있습니까?

즉, 주소를 핑 (ping)하면 IP에 PTR 레코드 (따라서 이름)가 있지만 해당 시스템에서 응답이없는 것입니다. 우리가 볼 때 서브넷 마스크가 잘못 설정되어 있거나 IP가 루프백 인터페이스에 바인딩되어 실수로 eth 인터페이스에 바인딩 된 경우가 가장 일반적입니다.

196.220은 무엇입니까? 196.211과의 관계는 무엇입니까? .220이 HA 프록시 호스트 중 하나라고 가정합니다. ifconfig -a & arp -a를 실행하면 무엇이 표시됩니까?

Max Clark이 말했듯이 <미완료>는 69.59.196.211이 69.59.196.220에 대한 ARP 요청을했지만 아직 응답을받지 못했다는 것을 의미합니다. (Windows-land에서는 이것을 "00-00-00-00-00-00-00"에 대한 ARP 매핑으로 볼 수 있습니다. BTW, 그런 ARP 매핑이 보이지 않는 것이 이상합니다. 69.59.196.211의 경우 69.59.196.220)

필자의 경험상 ARP는 일반적으로 항상 작업을 수행했기 때문에 정적 ARP 항목을 사용하지 않는 경향이 있습니다.

그것이 나라면, "실패한"Windows 머신 (69.59.196.220)에서 적절한 이더넷 인터페이스를 스니핑하여 69.59.196.211에 대한 ARP를 관찰하고 69.59의 ARP 요청에 어떻게 / 응답하는지 관찰합니다. 196.211. 또한 tcpdump -i interface-name arpLinux 시스템 측면에서 ARP 트래픽이 어떻게 보이는지 확인하기 위해 게이트웨이 시스템에서 ARP 전용 ( )을 스니핑하는 것을 고려할 것 입니다.

나는에서 알고 블로그 백 엔드 네트워크와 프런트 엔드 네트워크를 가지고 있음. 이러한 중단 중에 "실패한"Windows 서버 (69.59.196.220)에 프런트 엔드 네트워크의 다른 컴퓨터와 통신하는 데 문제가 있습니까? 아니면 게이트웨이와 통신하는 데 문제가 있습니까? 당신이 행동에서 그것을 잡을 때 프론트 엔드 또는 백 엔드 네트워크를 통해 고장난 기계에오고 있는지 궁금합니다.

문제가 발생했을 때 "해결"하기 위해 무엇을하고 있습니까?

편집하다:

업데이트를 통해 문제를 해결하기 위해 "실패한"Windows 시스템을 재부팅하고 있음을 확인했습니다. 다음에 그렇게하기 전에 Windows 컴퓨터가 프런트 엔드 인터페이스에서 "통화"할 수 있는지 확인할 수 있습니까? 또한 route print실패하는 동안 Windows 시스템 ( ) 에서 라우팅 테이블의 사본을 가져 오십시오 . (기본적으로 NIC / 드라이버가 Windows 시스템에서 작동 할 것인지 확인하려고합니다.)

이 문서 는 여러 가지 상태를 보여줍니다 (표 2.1). 불완전하면 첫 번째 ARP 요청 (아마도 오래된, 지연, 프로브 이후)을 보냈지 만 아직 응답을받지 못한 것입니다.

haproxy 노드의 정적 ARP가 도움이되지 않는 이유는 웹 서버가 여전히 게이트웨이로 돌아가는 방법을 알 수 없기 때문입니다.

haproxy 노드 중 하나가 실패하면 웹 서버의 정적 ARP가 웹 서버가 게이트웨이를 전환하는 기능을 중단합니다. 가상 인터페이스가 haproxy 노드의 eth1과 동일한 MAC 주소를 공유한다고 생각합니다. 각 웹 서버에 두 게이트웨이 중 하나에 코드.

고장난 웹 서버에 어떤 종류의 보안 소프트웨어가 설치되어 있습니까? Symantec Endpoint Security가 설치된 Windows 2008 서버에서 긴 밤을 보냈습니다. 이는 네트워킹 스택에 일부 필터링 코드를 설치하여 게이트웨이의 ARP 패킷을 전혀 보지 못하게했습니다. (Microsoft에서 제공 한) 수정은 DLL을로드 한 레지스트리 항목을 제거하는 것이 었습니다.

다른 시간에이 문제가 발생하면 장치 관리자에서 전체 네트워크 어댑터를 제거하고 다시 설치하는 것이 도움이 된 것 같습니다.

arp 항목을 정적으로 설정 했으므로 서버 는 게이트웨이를 찾을 위치를 알고 있습니다. 그러나 스위치가 게이트웨이의 위치를 ​​모르면 패킷을 전달하지 않습니다.

HAproxy와 웹 서버간에 잘못된 (또는 혼란스러운) 스위치가있는 것 같습니다. 재부팅하십시오.

또는 HAproxy 서버가 어느 서버가 제어 중인지에 대해 동의하지 않으며 둘 다 .211에 대한 arp 조회에 응답하지 않습니다.

동일한 회선을 따라 스위치에 과부하가 걸리면 HAProxies가 서로 빠르게 통신하지 못하고 페일 오버됩니다.

다음에이 문제가 발생하면 해당 두 호스트에서 패킷 캡처를 실행하여 각각의 ARP 트래픽을 관찰하는 것이 좋습니다.

HAproxy 시스템은 아마도 tcpdump의 풍미를 가질 것입니다. 설치되어있을 것입니다. Windows 컴퓨터의 경우 Wireshark 또는 Microsoft Network Monitor 와 같은 WinPCAP 응용 프로그램이 필요합니다 .

실제로, 문제는 ARP에 문제가있는 것으로 보이므로 문제가있는 10MB의 롤링 캡처 파일을 사용하여 HAproxy 시스템과 Windows 시스템의 모든 ARP 트래픽을 지속적으로 기록 할 수 있습니다. 장애를 감지 할 때까지 캡처 파일에 장애 이전의 ARP 트래픽이 계속 포함되도록 충분히 커야합니다. (한 시간 정도 캡처를 실행하여 생성되는 데이터 양을 확인하여 실험 해 볼 가치가 있습니다).

Linux tcpdump에 대한 캡처 구문 예제 (참고 :이 기능을 테스트하는 데 편리한 Linux 상자가 없습니다. 프로덕션에서 사용하기 전에 -C 및 -W의 동작을 테스트하십시오!) :

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

이것은 정확하게 당신에게 무엇이 실패했는지에 대한 약간의 표시를 제공해야합니다. ARP 항목이 만료 된 경우 (및 이 기사 최신 버전의 Windows에서 '비활성'항목이 매우 적극적으로 것처럼 보입니다) 다음과 같은 상황이 발생할 것으로 예상합니다.

1. 소스 호스트는 ARP 요청을 대상 호스트에 보냅니다. ARP 요청은 일반적으로 브로드 캐스트되지만 호스트가 기존 항목을 새로 고치는 경우 ARP는 유니 캐스트로 전송 될 수 있습니다.
2. 대상 호스트는 ARP 응답으로 응답합니다. 99 %의 시간이 유니 캐스트이지만 RFC 는 브로드 캐스트 응답을 허용합니다. ( IPv4 주소 충돌 감지 에 관한 RFC 참조 에 ).

들리는 것처럼 간단하지만이 과정을 방해 할 수있는 다른 것들이 있습니다.

• 원래 요청이 대상에 도착하지 않았을 수 있습니다.
• 요청이 목표에 도달했지만 응답이 소스에 도달하지 않았을 수 있습니다.
• 어떤 종류의 고 가용성 메커니즘이 ARP의 '정상적인'동작을 방해 할 수 있습니다.
  • HAProxy 노드 간의 장애 조치는 어떻게 작동합니까? 공유 MAC 주소를 사용합니까, 아니면 무상 ARP를 사용하여 노드간에 IP 주소를 페일 오버합니까?
  • 위의 ARP 테이블에있는 많은 MAC 주소는 00-15-5D로 시작하며 Microsoft에 등록되어 있습니다. 문제가있는 Windows 시스템에서 클러스터링 또는 기타 HA를 사용하고 있습니까? 이 00-15-5D MAC 주소는 Windows 서버에서 'ipconfig / all'을 수행 할 때 하드웨어 NIC와 관련된 것과 동일한 것입니까?

이것이 다시 일어날 때 / 확인할 사항 :

• ARP 트래픽의 패킷 캡처를보십시오. 대화의 어떤 부분도 분명히 일어나지 않았습니까?
• 스위치의 브리징 / CAM 테이블을 점검하십시오. 문제의 모든 MAC 주소가 원하는 포트에 매핑됩니까?
• 서브넷의 다른 호스트에 Windows 및 HAProxy 호스트의 IP 주소에 유효한 ARP 항목이 있습니까?
• 여러 다른 소스 시스템에서 동일한 대상 IP에 대한 ARP 항목이 동일한 MAC 주소로 해석됩니까? 즉, 서브넷의 다른 두 호스트에 로그온하고 196.211이 두 호스트에서 동일한 MAC 주소로 확인되는지 확인하십시오.

우리는 2008 R2 터미널 서버 중 하나에서 NIC의 모든 트래픽이 중지되었지만 연결 상태를 유지하고 NIC LED에 통신이 표시되는 비슷한 문제가있었습니다. 이것은 일주일에 2-3 번 자르는 지속적인 문제 였지만 가동 시간은 약 12-13 시간 (서버는 밤에 재부팅) 후에야 발생했습니다.

NetbalancerService 서비스 종료를 시도한 후 (호기심에서) Seriousbit Netbalancer가 원인이라는 것을 알았습니다. 그런 다음 트래픽이 인터페이스를 가로 질러 이동하기 시작했습니다. 이후 Netbalancer를 제거했습니다.

Asus Mainboard lan과 같은 문제가있었습니다. realtek 웹 사이트 에서 최신 드라이버를 설치하여 수정되었습니다.