Windows 2008 bỏ qua các yêu cầu ARP miễn phí


38

Gần đây chúng tôi đã thấy một sự cố sau sự cố về bộ định tuyến của chúng tôi, nơi Windows 2008 Box của chúng tôi đã không bắt đầu nói chuyện với bộ định tuyến chính sau khi bị lỗi.

Khi chúng tôi thực hiện một số hoạt động đào, họ vẫn có mục ARP từ bộ định tuyến thứ cấp. Theo Blog TechNet, đây là thiết kế phụ:

Đầu tiên, Windows Vista hoặc Windows Server 2008 sẽ không cập nhật bộ đệm Neighbor nếu nhận được phát sóng ARP trừ khi đó là một phần của yêu cầu ARP quảng bá cho người nhận . Điều này có nghĩa là khi một ARP vô cớ được gửi trên mạng với Windows Vista và Widows Server 2008, các hệ thống này sẽ không cập nhật bộ đệm của họ với thông tin không chính xác nếu có xung đột địa chỉ IP.

Thứ hai, có vẻ như windows xóm-cache (arp-cache) chỉ được cập nhật nếu máy không còn có thể nói chuyện với máy hiện đang trong bộ đệm. Nó không gửi các yêu cầu ARP không thường xuyên để đảm bảo bộ đệm không bị cũ. Mặc dù đây không phải là vấn đề trong lần thất bại ban đầu, trong khi thất bại trở lại khi cả hai hộp còn sống, điều này khiến các cửa sổ tiếp tục nói chuyện với hộp phụ.

Có cách nào để buộc Windows 2008 chấp nhận các yêu cầu ARP miễn phí không?


Câu trả lời:


8

Sau khi kiểm tra, có vẻ như Hotfix 2582281 đã khắc phục sự cố. Bạn có thể nhận được hotfix mà không phải trả tiền hỗ trợ bằng cách sử dụng trang yêu cầu hotfix của họ .

Tôi đã chạy thử nghiệm điều này bằng cách sử dụng arpingvà chưa được vá windows 2008 R2. Tôi đã thêm một IP thứ cấp, 64.34.119.80, vào một máy có cùng phân khúc L2 mạng. Sau đó tôi đã ban hành lệnh sau từ một máy khác , mạng ( sudo arping -U 64.34.119.80 -I bond0 -c1). Ngay sau đó, tôi đã ping 64.34.119.80 từ hộp cửa sổ sau khi thấy nó nhận được arp trong wireshark. Sau đó tôi đã áp dụng các hotfix và lặp lại thử nghiệm.

Ngoài ra, có vẻ như lệnh arping không cần sử dụng địa chỉ MAC unicast mà thay vào đó là MAC quảng bá vì đây là loại GVD duy nhất bị bỏ qua trong các thử nghiệm của tôi.

Trước khi vá:

nhập mô tả hình ảnh ở đây

Trong bản chụp wireshark này, ping sau khi yêu cầu Gkv không được gửi đến MAC Destination mà Gkv đến từ đó, vì vậy bạn có thể thấy rằng Gkv đang bị bỏ qua.

Sau khi vá:

nhập mô tả hình ảnh ở đây

Trong thử nghiệm này, sau bản vá, yêu cầu Gkv dường như được thực hiện khi ping được gửi đến địa chỉ MAC mà GARP xuất phát.

Vì vậy, từ các thử nghiệm này, có vẻ như hotfix 2582281 đã khắc phục vấn đề phát sóng Gkv bị bỏ qua.


4

Khi nghiên cứu vấn đề TCPIP của riêng tôi vừa rồi, tôi tình cờ thấy Hotfix rất thú vị này:

http://support.microsoft.com/kb/2582281

Nguyên nhân:

Sự cố này xảy ra do ngăn xếp TCP / IP của máy chủ ứng dụng bỏ qua các yêu cầu Giao thức phân giải địa chỉ (ARP) không chính xác.

Điều này nghe có vẻ rất khủng khiếp giống như những gì bạn đang chạy vào. Và nó cũng là một hotfix hoàn toàn mới, được phát hành vào ngày 22 tháng 7 năm 2011, vì vậy bạn đã không gặp nó khi lần đầu tiên chạy vào nó.


Hình như KB này biến mất?
Kyle Brandt

@KyleBrandt Nó đã ở đó, và bây giờ nó đã biến mất. Tôi tự hỏi liệu vấn đề này có được bao gồm trong gói dịch vụ / cập nhật ở nơi khác không, có thể là vấn đề này: support.microsoft.com/kb/2578103
sysadmin1138

3

Thử netsh interface ipv4 set interface x basereachable=ytrong đó x là chỉ số giao diện và y là thời gian chờ ARP tính bằng mili giây mà bạn muốn. Hãy nhớ làm điều đó từ một dấu nhắc lệnh với đặc quyền quản trị viên!


2
Điều đó thực sự chỉ điều chỉnh thời gian giữa khi bộ đệm hàng xóm nghĩ rằng mục nhập cũ và có thể truy cập được. Nếu cả hai hộp HA đều hoạt động vào thời điểm không hoạt động trở lại, thì Windows sẽ không bao giờ xem nó là cũ và tái phát.
Zypher

1
Tôi không nghĩ có cách nào để buộc Windows chấp nhận ARP vô cớ. Trong thực tế, tôi đã phải hạ thấp thời gian cơ bản để đạt được failover / failback trong một kịch bản khác vì điều này.

3

Bạn đang sử dụng giao thức dự phòng hop đầu tiên nào?

Tôi biết điều này không trả lời trực tiếp câu hỏi của bạn, tuy nhiên VRRP (và tổ tiên độc quyền của nó, HSRP) sử dụng địa chỉ MAC được chia sẻ được lật sang cổng chuyển đổi mới khi bộ định tuyến chính thay đổi. Điều này xoay quanh nhu cầu về một ARP vô cớ.


1

Điều kiện tiên quyết
1. WinPCAP 4.0.1 (phiên bản 4.1.2 không hoạt động)
- http://www.winpcap.org/archive/4.0.1-WinPcap.exe (Phiên bản Windows)
2. Wireshark 1.6.7
3. Đã tắt IPv6 trên giao diện mạng, do hạn chế arping
4. arping
- http://mathieu.carbou.free.fr/pub/arping/2.06/arping.zip (Windows Binary)

Thực thi
1. Nhận Tên Inteface
- "E: \ Tệp chương trình \ Wireshark \ tshark.exe "-D
- Từ chi tiết giao diện của Wireshark
2. Thực thi arping, để gửi yêu cầu Gratuitous ARP
- arping.exe -A -i \ Device \ NPF_ {4399F778-AF25-4B6D-AFFB-A1F2C7 -c 3 -S 10.20.30.50
Trong đó 10.20.30.50 là ipaddress bạn muốn thông báo cho mạng (bộ định tuyến)


-4

Tôi đã gặp điều này trên liên kết từ http://blog.serverfault.com/post/windows-2008-and-broken-arp/ .

Nếu bạn hỏi trên stackoverflow, bạn có thể đã sửa chữa nhanh hơn nhiều.

Đánh hơi các gói Gkv và chạy arp -s inet_addr eth_addr.

Đừng làm điều này nếu có cơ hội xa nhất để có được một máy thù địch trong mạng LAN của bạn.


Đó không thực sự là một sửa chữa. Đó là một cách giải quyết hoạt động trên một máy. Hành vi vẫn bị phá vỡ. Tất cả những gì đang làm là tự thay đổi địa chỉ trong bảng arp, không khắc phục nguyên nhân gốc của hành vi.
Zypher
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.