เป็นเรื่องปกติหรือไม่ที่ ISP จะมี IP เดียวกันสองครั้งในเส้นทาง

หากฉันติดตามออกจากเครือข่ายในบ้านของฉันฉันเห็น IP เดียวกันสองครั้งติดต่อกันหลังจากเราเตอร์ของฉัน:

  1     1 ms     1 ms     1 ms  router
  2    17 ms    16 ms    16 ms  217.0.117.61
  3    16 ms    16 ms    16 ms  217.0.117.61
  4    17 ms    17 ms    17 ms  87.186.233.102
  5    26 ms    24 ms    24 ms  217.239.39.2
  6    24 ms    24 ms    25 ms  ...

นี่เป็นเรื่องปกติหรืออาจเป็นการตั้งค่าผิดพลาดในนามของ ISP หรือไม่

หากเกิดขึ้นครั้งเดียวหรือน้อยครั้ง

แพ็กเก็ต IP ทั้งหมดมีฟิลด์time-to-live ( TTL ) ฟิลด์นี้จะลดลงหนึ่งโดยเราเตอร์ทุกคนที่ส่งต่อแพ็คเก็ต หากเราเตอร์ลด TTL เป็น 0 มันจะลดแพ็กเก็ตและสร้างICMP TTL เกินกว่าแพ็คเก็ตข้อผิดพลาดและส่งกลับไปที่ผู้ส่ง

Traceroute ใช้คุณสมบัตินี้เพื่อส่งแพ็กเก็ตที่เพิ่ม TTL ตามลำดับ สิ่งนี้อนุญาตให้ traceroute สร้างรูปภาพของเส้นทางระหว่างต้นทางและปลายทาง

ในกรณีของคุณอาจมีสองเส้นทางที่เป็นไปได้จากเราเตอร์ของคุณไปที่ 217.0.117.61 ซึ่งมีความยาวมากกว่าอีกเส้นทางหนึ่ง ดังนั้นสิ่งที่เกิดขึ้นคือ:

1. แพ็คเก็ตที่ส่งด้วย TTL = 1 มาถึงเราเตอร์ของคุณซึ่งตอบแล้ว
2. แพ็คเก็ตที่ส่งด้วย TTL = 2
   • ถึงเราเตอร์ของคุณซึ่งลด TTL เป็น 1 และส่งไปที่
   • จากนั้นถึง 217.0.117.61 ซึ่งตอบ
3. แพ็คเก็ตที่ส่งด้วย TTL = 3
   • ถึงเราเตอร์ของคุณซึ่งลด TTL เป็น 2 และส่งไปที่
   • จากนั้นไปถึงเราเตอร์ที่ไม่รู้จักบางตัวซึ่งลด TTL เป็น 1 แล้วส่งต่อ
   • จากนั้นถึง 217.0.117.61 ซึ่งตอบ

นั่นคือเหตุผลที่คุณมีรายการเดียวกันสองครั้ง มันอาจจะแย่กว่านั้นด้วยIP ทุกตัวที่อยู่ในรายการสองครั้ง แต่เห็นได้ชัดว่าเราเตอร์ให้คำตอบแรก 217.0.117.61 ไม่เคยมีส่วนร่วมในการติดตามอีกครั้งดังนั้นแพ็กเก็ตต่อไปนี้ทั้งหมดผ่านเราเตอร์ที่ไม่รู้จัก

หากสิ่งนี้เกิดขึ้นเสมอ

จากนั้นเป็นเพราะวิธีการที่ ISP ของคุณตั้งค่าเครือข่าย IP ในรายการของคุณเป็นของ Deutsche Telekom AG ซึ่งมีเครือข่ายภายในขนาดใหญ่ที่มีโหนดที่ซับซ้อนและมีประสิทธิภาพสูงซึ่งหนึ่งในนั้นดูเหมือนจะตอบคำถามสองครั้ง

มีคำอธิบายที่เป็นไปได้สองสามข้อ:

• ISP มีไฟร์วอลล์ที่ตอบคำขอการติดตามข้อมูล ไฟร์วอลล์ขององค์กรเป็นคอมพิวเตอร์เฉพาะทางในสิทธิ์ของตนเอง มันอาจตอบคำขอ tracroute หากถูกโปรแกรมไปด้วยที่อยู่ IP ที่ตั้งโปรแกรมไว้ซึ่งอาจเป็นของโหนดที่กำลังปกป้อง

• เราเตอร์ขององค์กรอาจตอบจากทั้งอินเทอร์เฟซภายในและภายนอก เราเตอร์ความเร็วสูงและปริมาณงานสูงเช่นจริง ๆ แล้วเป็นเครือข่ายในกล่องพร้อมกับเราเตอร์ย่อยพิเศษเป็นส่วนประกอบ คำตอบอาจมาจากทั้งเราเตอร์ย่อยไปข้างหน้าและข้างหลังซึ่งตอบกลับด้วย IP เดียวกัน

เนื่องจากมันเกิดขึ้นอย่างสม่ำเสมอฉันคิดว่าสาเหตุที่เป็นไปได้มากที่สุดคือข้อผิดพลาดในเฟิร์มแวร์ตัวใดตัวหนึ่งของเราเตอร์ที่ทำให้มันไม่สามารถวางแพ็กเก็ตการติดตามได้ (และส่งรายงาน "เกิน TTL") เมื่อมันควรหรือส่งก่อน ควร นี่คือตัวอย่างของปัญหาแรกจากหน้า man traceroute BSD :

A sample use and output might be:

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
 1 helios.ee.lbl.gov (128.3.112.1)  19 ms 19 ms  0 ms
 2 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 [...]

Note that lines 2 & 3 are the same.  This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).

ในตัวอย่างนี้เป็นเราเตอร์ตัวที่สองที่มีข้อผิดพลาดและเราเตอร์ตัวที่สามจะแสดงขึ้นเป็นทั้ง # 2 และ # 3

พิจารณาว่าจะเกิดอะไรขึ้นถ้าเราเตอร์ที่สองมีข้อผิดพลาดที่ทำให้แพ็กเก็ตหล่นเมื่อ TTL ถึง 1 แทน 0:

1. แพ็คเก็ตการติดตามที่ส่งด้วย TTL = 1 จะลดลงเป็น 0 ที่เราเตอร์แรกซึ่งลดลงและรายงานเกิน TTL ดังนั้นจึงปรากฏเป็น hop # 1 ทุกอย่างดีที่นี่
2. แพ็คเก็ตที่ส่งด้วย TTL = 2 จะลดลงเป็น 1 ที่เราเตอร์แรก จากนั้นเราเตอร์ที่สองจะลดลงเป็น 0 และลดลงและรายงานและจะปรากฏเป็น hop # 2 ดีอีกครั้งที่นี่ทั้งหมด
3. แพ็คเก็ตที่ส่งด้วย TTL = 3 จะลดลงเป็น 2 ที่เราเตอร์แรก จากนั้นเราเตอร์ที่สองจะลดค่าลงเป็น 1 และจะลดลงอย่างไม่ถูกต้องและรายงานและจะปรากฏขึ้นในลักษณะ hop # 3

อีกครั้งเป็นเราเตอร์ที่สองที่มีข้อผิดพลาด แต่ในกรณีนี้เราเตอร์ที่สองที่มีการระบุไว้สองครั้ง (ในตัวอย่างในหน้า man เป็นที่สามที่มีการระบุไว้สองครั้ง)