Điểm:0

Lưu lượng NTP gây ra các yêu cầu ARP thường xuyên

lá cờ in

Tôi đang chạy Ubuntu LTS 22.04 bằng Chrony làm máy chủ NTP. Tôi phát hiện ra rằng ngay cả với lưu lượng NTP thường xuyên giữa máy khách NTP và Máy chủ NTP, các yêu cầu ARP vẫn được gửi qua lại rất thường xuyên. Theo mặc định, bộ đệm ARP hết hạn sau 60 giây.

Nó là một lỗi?

09:32:28.116858 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:32:28.117032 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:32:30.117770 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:32:30.117936 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:32:33.116704 ARP, Yêu cầu ai có 10.68.1.1 cho biết 10.68.1.2, độ dài 46
09:32:33.116750 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, độ dài 28
09:32:33.190181 ARP, Yêu cầu ai có 10.68.1.2 cho biết 10.68.1.1, độ dài 28
09:32:33.190327 ARP, Trả lời 10.68.1.2 is-at 00:90:e8:9d:aa:dc, độ dài 46
09:32:46.117215 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:32:46.117470 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:32:48.117032 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:32:48.117277 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:04.116931 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:04.117104 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:06.116888 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:06.117144 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:09.286195 ARP, Yêu cầu ai có 10.68.1.2 cho biết 10.68.1.1, độ dài 28
09:33:09.286332 ARP, Trả lời 10.68.1.2 is-at 00:90:e8:9d:aa:dc, độ dài 46
09:33:22.116699 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:22.116833 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:24.116869 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:24.117034 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:27.116688 ARP, Yêu cầu ai có 10.68.1.1 cho biết 10.68.1.2, độ dài 46
09:33:27.116751 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, độ dài 28
09:33:40.116842 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:40.117011 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:42.116923 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:42.117089 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:33:45.126169 ARP, Yêu cầu ai có 10.68.1.2 cho biết 10.68.1.1, độ dài 28
09:33:45.126332 ARP, Trả lời 10.68.1.2 is-at 00:90:e8:9d:aa:dc, độ dài 46
09:33:58.116928 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:33:58.117095 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:00.116873 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:00.117039 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:16.116895 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:16.117154 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:18.116863 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:18.117029 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:21.116733 ARP, Yêu cầu ai có 10.68.1.1 cho biết 10.68.1.2, độ dài 46
09:34:21.116768 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, độ dài 28
09:34:21.222128 ARP, Yêu cầu ai có 10.68.1.2 cho biết 10.68.1.1, độ dài 28
09:34:21.222294 ARP, Trả lời 10.68.1.2 is-at 00:90:e8:9d:aa:dc, độ dài 46
09:34:34.116899 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:34.117069 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:36.127025 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:36.127269 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:52.116889 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:52.117145 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:54.116943 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:34:54.117187 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:34:57.318148 ARP, Yêu cầu ai có 10.68.1.2 cho biết 10.68.1.1, độ dài 28
09:34:57.318299 ARP, Trả lời 10.68.1.2 is-at 00:90:e8:9d:aa:dc, độ dài 46
09:35:10.116983 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:35:10.117159 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:35:12.116865 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Máy khách, độ dài 48
09:35:12.117031 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Máy chủ, độ dài 48
09:35:15.116750 ARP, Yêu cầu ai có 10.68.1.1 cho biết 10.68.1.2, độ dài 46
09:35:15.116810 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, độ dài 28
lá cờ cn
Tôi tin rằng nó được đề cập ở đây: https://serverfault.com/a/924165/20701. Điều này tương tự như hành vi trong Windows, thời gian chờ là không xác định.
R SONG avatar
lá cờ in
Cảm ơn Greg. Tôi cũng nhận thấy bài viết đó. Hãy đồng ý rằng theo mặc định, bộ nhớ cache ARP sẽ hết hạn trong khoảng từ 15 đến 45 giây. Mục nhập bộ nhớ cache ARP hết hạn nếu nó không được sử dụng. Nếu có lưu lượng truy cập thường xuyên hơn 15 giây sử dụng địa chỉ ip/MAC đó, thì mục ARP đó sẽ không hết hạn, phải không?
lá cờ cn
Nên đủ dễ dàng để kiểm tra. Không có NTP.
Điểm:0
lá cờ ru

Đó là điều hoàn toàn bình thường và không phải lỗi.

Các mục trong bảng ARP chỉ được làm mới hoặc cập nhật bởi các gói ARP (phản hồi ARP hoặc yêu cầu ARP được tạo dưới dạng ARP miễn phí tin nhắn), không phải bởi các gói IP. Do đó, các mục hết thời gian ngay cả khi chúng được sử dụng thường xuyên và cần được cập nhật bởi các yêu cầu/trả lời ARP.

R SONG avatar
lá cờ in
Cảm ơn Zac67. Tôi đã có ấn tượng sai lầm. Tôi nghĩ rằng mục nhập ARP sẽ không hết hạn miễn là nó được truy cập thường xuyên. Tuy nhiên, bộ phản hồi ARP có nên cập nhật bộ đệm ARP của chính nó khi nhận được yêu cầu ARP không? Ví dụ: máy A gửi yêu cầu ARP đến Máy chủ B, máy B cũng sẽ cập nhật mục nhập ARP cho Máy A chứ? Trong tcpdump ở trên, 10.68.1.2 đã gửi yêu cầu ARP tới 10.68.1.1, 10.68.1.1 đã phản hồi, ngay sau đó, 10.68.1.1 đã gửi yêu cầu ARP tới 10.68.1.2 và 10.68.1.2 đã phản hồi. Tại sao điều đó là cần thiết?
Zac67 avatar
lá cờ ru
Một yêu cầu ARP chỉ cập nhật bảng ARP khi nó được tạo dưới dạng một thông báo *gratuitous ARP* (TPA=SPA, THA=zero), các yêu cầu ARP bình thường không cập nhật ARP.
R SONG avatar
lá cờ in
Cảm ơn Zac67. [link](http://manpages.ubuntu.com/manpages/bionic/man7/arp.7.html) ... Phản hồi tích cực có thể nhận được từ lớp cao hơn ... **base_reachable_time (kể từ Linux 2.2) Một lần một người hàng xóm đã được tìm thấy, mục nhập được coi là hợp lệ với ít nhất một giá trị ngẫu nhiên giữa base_reachable_time/2 và 3*base_reachable_time/2. _Hiệu lực của một mục nhập sẽ được gia hạn nếu nó nhận được phản hồi tích cực từ các giao thức cấp cao hơn._** Có vẻ như giao thức khác có thể gia hạn hiệu lực cho các mục nhập ARP. Vấn đề là tại sao Chrony của NTP hay NTP nói chung không làm điều đó?
Zac67 avatar
lá cờ ru
Phản hồi tích cực=khung đã nhận từ địa chỉ MAC không kéo dài thời gian tồn tại của mục nhập, nó chỉ ngăn việc rút ngắn mục nhập. "Khi một người hàng xóm đã được tìm thấy" đề cập đến việc giải quyết ARP thành công. Tuy nhiên, máy chủ lưu trữ và các triển khai của chúng hoàn toàn không có chủ đề ở đây, hãy xem [trợ giúp/về chủ đề].

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.