traceroute: บางครั้งเราเตอร์ไม่ตอบสนองและผู้ใช้เห็นการหมดเวลา

ฉันเป็นผู้ดูแลระบบเครือข่ายขนาดเล็ก และฉันกำลังตรวจสอบปัญหาที่ผู้ใช้บ่น ต้นตอของการร้องเรียนของพวกเขาคือ ติดตามเส้นทาง: บางครั้งเราเตอร์ตามเส้นทางก็ไม่ตอบสนอง ติดตามเส้นทาง โพรบและผู้ใช้เห็นการหมดเวลา (เหล่านั้น *แทน ร.ฟ.ท.)

เครือข่ายประกอบด้วยเราเตอร์ Linux สองสามตัวที่เชื่อมต่อด้วยอีเทอร์เน็ต/ไร้สาย เราเตอร์ Linux ไม่ได้ใช้งาน 99%, การใช้งานลิงก์ 20 mbit/s, 2000 แพ็กเก็ต/s ระบบไร้สายเป็นหินที่แข็งแกร่ง PING ไปยังเราเตอร์ทั้งหมดตามเส้นทางคือ 10 มิลลิวินาทีโดยมีการเปลี่ยนแปลงบางอย่าง PING น้ำท่วมไปยังโฮสต์ใด ๆ เหล่านั้นทำงานเป็นเวลาหลายนาทีโดยไม่มีการสูญเสียแพ็กเก็ต (และฉันหมายถึง 0 แพ็กเก็ตที่หายไป) การดาวน์โหลดไฟล์ขนาดใหญ่ผ่านเครือข่าย: เฉลี่ย 10.2 MB/s

ตัวอย่าง ถูกต้อง ติดตามเส้นทาง มีลักษณะดังนี้:

# traceroute -nI 10.0.0.2
ติดตามเส้นทางไปยัง 10.0.0.2 (10.0.0.2), สูงสุด 30 hops, 60 แพ็คเก็ตไบต์
 1 192.168.0.1 3.919 มิลลิวินาที 3.866 มิลลิวินาที 4.117 มิลลิวินาที
 2 10.41.13.1 4.149 มิลลิวินาที 6.714 มิลลิวินาที 6.707 มิลลิวินาที
 3 10.41.1.11 8.475 มิลลิวินาที 8.468 มิลลิวินาที 8.705 มิลลิวินาที
 4 10.0.0.2 8.697 มิลลิวินาที 9.428 มิลลิวินาที 9.707 มิลลิวินาที

เดอะ มีปัญหา ติดตามเส้นทางมีลักษณะดังนี้:

# traceroute -nI 10.0.0.2
ติดตามเส้นทางไปยัง 10.0.0.2 (10.0.0.2), สูงสุด 30 hops, 60 แพ็คเก็ตไบต์
 1 192.168.0.1 3.190 มิลลิวินาที 3.140 มิลลิวินาที 3.128 มิลลิวินาที
 2 10.41.13.1 3.119 มิลลิวินาที 3.113 มิลลิวินาที *
 3 10.41.1.11 3.697 มิลลิวินาที * 3.683 มิลลิวินาที
 4 10.0.0.2 4.531 มิลลิวินาที 4.524 มิลลิวินาที 5.171 มิลลิวินาที
# traceroute -nI 10.0.0.2
ติดตามเส้นทางไปยัง 10.0.0.2 (10.0.0.2), สูงสุด 30 hops, 60 แพ็คเก็ตไบต์
 1 192.168.0.1 3.471 มิลลิวินาที 3.405 มิลลิวินาที 3.388 มิลลิวินาที
 2 10.41.13.1 3.372 มิลลิวินาที 3.359 มิลลิวินาที 3.350 มิลลิวินาที
 3 10.41.1.11 5.039 ms * *
 4 10.0.0.2 5.105 มิลลิวินาที 5.484 มิลลิวินาที 5.473 มิลลิวินาที

ฉันตรวจสอบเล็กน้อยกับ tcpdump และพบว่า ติดตามเส้นทาง ทำงานเช่นนี้:

1. ในตอนแรก ส่งคำขอ ICMP จำนวนมากที่มี TTL 1, 2, 3, 4, 5, 6 แต่ละ TTL จะถูกส่ง 3 ครั้ง นั่นคือ 18 แพ็คเก็ต :)
2. รอสักครู่สำหรับการตอบกลับทั้งหมด (เกินเวลา).
3. เมื่อการตอบกลับทั้งหมดกลับมา แสดงผลลัพธ์
4. ..หรือรอให้หมดเวลาและแสดงผลลัพธ์โดยไม่มีการตอบกลับที่มีเครื่องหมายดอกจัน

และสาเหตุของการหมดเวลาคือ - เราเตอร์ได้รับคำขอที่เกี่ยวข้องทั้งหมด 3 รายการ แต่บางครั้งไม่ตอบสนอง ไม่ส่ง ICMP Time Exceeded

ฉันสงสัยว่ามีการตั้งค่าบางอย่างที่ตั้งค่าลักษณะการทำงานนี้บนเราเตอร์ กล่าวคือ icmp_ratelimit, icmp_ratemask, icmp_msgs_per_sec และ icmp_msgs_burst. ทั้งหมดอธิบายอย่างใด ที่ kernel.org เอกสาร. และนี่คือจุดที่ฉันล้มเหลว ฉันไม่ได้มาพร้อมกับค่าใด ๆ ของตัวแปรเหล่านั้นเพื่อสร้าง ติดตามเส้นทาง ทำงานตลอดเวลา

ฉันลองตั้งค่านี้บนเราเตอร์ทั้งหมด:

• icmp_ratelimit ตั้งค่าให้ 0 (ไม่จำกัดอะไร)
• icmp_msgs_per_sec ตั้งค่าให้ 10000 (ควรสูงพอ)
• icmp_msgs_burst ตั้งค่าให้ 5000 (สูงเหนือ)

มันไม่ได้ช่วยอะไรฉันเลย ฉันเห็นพฤติกรรมแบบเดียวกันหมดเวลาแบบสุ่ม ฉันไม่ได้ยุ่งด้วย icmp_ratemaskเพราะฉันไม่เข้าใจวิธีการยกเว้นอย่างถ่องแท้ เกินเวลามาจากการจำกัด

ในที่สุดคำถาม:

1. หากคุณคุ้นเคยกับประเภทนี้ ติดตามเส้นทาง ปัญหาคุณแก้ไขได้อย่างไร?
2. หากคุณคุ้นเคยกับการตั้งค่าเคอร์เนลที่กล่าวถึงข้างต้น ค่าใดที่ "ดีพอ"
3. วิธีที่ถูกต้องในการแก้ไขคืออะไร icmp_ratemask ไม่จำกัด เกินเวลา ข้อความที่ต้องทำ ติดตามเส้นทาง ทำงานโดยไม่มีข้อผิดพลาด?
4. และพิเศษ - มีการละเมิดความปลอดภัยเมื่อเปลี่ยนการตั้งค่าเหล่านี้ (หรือที่เกี่ยวข้อง) หรือไม่ ฉันไม่ต้องการเป็น DoS'ed หรือเป็นแหล่งโจมตี DDoS ของใคร

เนื่องจากเป็นส่วนหนึ่งของนโยบายระนาบการควบคุมบนโพรบ ICMP ของฮอปส์ ส่วนใหญ่จะถูกละเว้น ฉันขอแนะนำอินสแตนซ์การสูบบุหรี่ในเบื้องต้นโดยเฉพาะ หากคุณต้องการข้อมูลประวัติที่ละเอียดยิ่งขึ้นในแง่ของเมตริกและแนวโน้ม