Score:0

ทราฟฟิก NTP ทำให้เกิดการร้องขอ ARP บ่อยครั้ง

ธง in

ฉันใช้ Ubuntu LTS 22.04 โดยใช้ Chrony เป็นเซิร์ฟเวอร์ NTP ฉันค้นพบว่าแม้จะมีทราฟฟิก NTP ระหว่างไคลเอนต์ NTP และเซิร์ฟเวอร์ NTP บ่อยครั้ง คำขอ ARP ก็ยังถูกส่งไปมาบ่อยครั้งมาก ตามค่าเริ่มต้น แคช ARP จะหมดอายุภายใน 60 วินาที

มันเป็นข้อผิดพลาดหรือไม่?

09:32:28.116858 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:32:28.117032 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:32:30.117770 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:32:30.117936 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:32:33.116704 ARP, Request who-has 10.68.1.1 บอก 10.68.1.2 ยาว 46
09:32:33.116750 ARP, ตอบกลับ 10.68.1.1 is-at 20:7c:14:a0:b9:a1, ยาว 28
09:32:33.190181 ARP, Request who-has 10.68.1.2 บอก 10.68.1.1 ความยาว 28
09:32:33.190327 ARP, ตอบกลับ 10.68.1.2 is-at 00:90:e8:9d:aa:dc, ความยาว 46
09:32:46.117215 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:32:46.117470 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:32:48.117032 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:32:48.117277 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:04.116931 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:04.117104 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:06.116888 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:06.117144 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:09.286195 ARP, Request who-has 10.68.1.2 บอก 10.68.1.1 ยาว 28
09:33:09.286332 ARP, ตอบกลับ 10.68.1.2 is-at 00:90:e8:9d:aa:dc, ความยาว 46
09:33:22.116699 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:22.116833 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:24.116869 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:24.117034 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:27.116688 ARP, Request who-has 10.68.1.1 บอก 10.68.1.2 ยาว 46
09:33:27.116751 ARP, ตอบกลับ 10.68.1.1 is-at 20:7c:14:a0:b9:a1, ความยาว 28
09:33:40.116842 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:40.117011 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:42.116923 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:42.117089 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:33:45.126169 ARP, Request who-has 10.68.1.2 บอก 10.68.1.1 ยาว 28
09:33:45.126332 ARP, ตอบกลับ 10.68.1.2 is-at 00:90:e8:9d:aa:dc, ความยาว 46
09:33:58.116928 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:33:58.117095 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:00.116873 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:00.117039 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:16.116895 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:16.117154 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:18.116863 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:18.117029 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:21.116733 ARP, Request who-has 10.68.1.1 บอก 10.68.1.2 ยาว 46
09:34:21.116768 ARP, ตอบกลับ 10.68.1.1 is-at 20:7c:14:a0:b9:a1, ความยาว 28
09:34:21.222128 ARP, Request who-has 10.68.1.2 บอก 10.68.1.1 ยาว 28
09:34:21.222294 ARP, ตอบกลับ 10.68.1.2 is-at 00:90:e8:9d:aa:dc, ความยาว 46
09:34:34.116899 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:34.117069 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:36.127025 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:36.127269 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:52.116889 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:52.117145 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:54.116943 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:34:54.117187 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:34:57.318148 ARP, Request who-has 10.68.1.2 บอก 10.68.1.1 ยาว 28
09:34:57.318299 ARP, ตอบกลับ 10.68.1.2 is-at 00:90:e8:9d:aa:dc, ความยาว 46
09:35:10.116983 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:35:10.117159 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:35:12.116865 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, ไคลเอ็นต์, ความยาว 48
09:35:12.117031 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, เซิร์ฟเวอร์, ความยาว 48
09:35:15.116750 ARP, Request who-has 10.68.1.1 บอก 10.68.1.2 ยาว 46
09:35:15.116810 ARP, ตอบกลับ 10.68.1.1 is-at 20:7c:14:a0:b9:a1, ยาว 28
cn flag
ฉันเชื่อว่าครอบคลุมที่นี่: https://serverfault.com/a/924165/20701 ซึ่งคล้ายกับลักษณะการทำงานใน Windows การหมดเวลานั้นไม่สามารถกำหนดได้
R SONG avatar
in flag
ขอบคุณเกร็ก ผมก็สังเกตกระทู้นั้นเหมือนกัน เรายอมรับว่าแคช ARP เริ่มต้นจะหมดอายุระหว่าง 15 ถึง 45 วินาที รายการแคช ARP จะหมดอายุหากไม่มีการใช้งาน หากมีการรับส่งข้อมูลบ่อยกว่า 15 วินาทีโดยใช้ที่อยู่ IP/MAC รายการ ARP นั้นไม่ควรหมดอายุใช่ไหม
cn flag
ควรจะง่ายพอที่จะทดสอบ ไม่มี NTP
Score:0
ธง ru

นั่นเป็นเรื่องปกติอย่างสมบูรณ์และไม่ใช่จุดบกพร่อง

รายการตาราง ARP จะได้รับการรีเฟรชหรืออัปเดตโดยแพ็กเก็ต ARP เท่านั้น (การตอบกลับ ARP หรือคำขอ ARP ที่สร้างขึ้นเป็น ARP ฟรี ข้อความ) ไม่ใช่โดยแพ็กเก็ต IP ดังนั้น รายการจึงหมดเวลาแม้ว่าจะมีการใช้งานบ่อยก็ตาม และจำเป็นต้องอัปเดตโดยคำขอ/ตอบกลับ ARP

R SONG avatar
in flag
ขอบคุณ Zac67 ฉันอยู่ภายใต้ความประทับใจที่ไม่ถูกต้อง ฉันคิดว่ารายการ ARP จะไม่หมดอายุตราบใดที่มีการเข้าถึงบ่อยครั้ง แต่ผู้ตอบกลับ ARP ควรอัปเดตแคช ARP ของตัวเองเมื่อได้รับคำขอ ARP ด้วยหรือไม่ ตัวอย่างเช่น โฮสต์ A ส่งคำขอ ARP ไปยังโฮสต์ B โฮสต์ B จะอัปเดตรายการ ARP สำหรับโฮสต์ A ด้วยหรือไม่ ใน tcpdump ด้านบน 10.68.1.2 ส่งคำขอ ARP ไปที่ 10.68.1.1 10.68.1.1 ตอบกลับ หลังจากนั้น 10.68.1.1 ส่งคำขอ ARP ไปที่ 10.68.1.2 และ 10.68.1.2 ตอบกลับ ทำไมถึงจำเป็น?
Zac67 avatar
ru flag
คำขอ ARP จะอัปเดตตาราง ARP เท่านั้นเมื่อสร้างเป็น *ข้อความ ARP ฟรี* (TPA=SPA, THA=ศูนย์) คำขอ ARP ปกติจะไม่อัปเดต ARP
R SONG avatar
in flag
ขอบคุณ Zac67 [ลิงค์](http://manpages.ubuntu.com/manpages/bionic/man7/arp.7.html) ... สามารถรับข้อเสนอแนะเชิงบวกได้จากเลเยอร์ที่สูงกว่า ... **base_reachable_time (ตั้งแต่ Linux 2.2) ครั้งเดียว พบเพื่อนบ้าน รายการจะถือว่าถูกต้องสำหรับค่าสุ่มอย่างน้อยระหว่าง base_reachable_time/2 และ 3*base_reachable_time/2 _An ความถูกต้องของรายการจะถูกขยายหากได้รับข้อเสนอแนะในเชิงบวกจากโปรโตคอลระดับที่สูงกว่า _** ดูเหมือนว่าโปรโตคอลอื่นๆ สามารถขยายความถูกต้องของรายการ ARP ได้ ปัญหาคือเหตุใด NTP หรือ NTP ของ Chrony โดยทั่วไปจึงไม่ทำเช่นนั้น
Zac67 avatar
ru flag
ข้อเสนอแนะในเชิงบวก=เฟรมที่ได้รับจากที่อยู่ MAC ไม่ได้ช่วยยืดอายุการใช้งานของรายการ แต่เพียงป้องกันการทำให้สั้นลง "เมื่อพบเพื่อนบ้านแล้ว" หมายถึงการแก้ปัญหา ARP ที่ประสบความสำเร็จ อย่างไรก็ตาม โฮสต์และการใช้งานไม่ตรงประเด็นที่นี่ โปรดดูที่ [help/on-topic]

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา