traceroute - พิมพ์แพ็คเก็ตเส้นทางไปยังโฮสต์ของเครือข่าย
สรุป
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ]
[ -i iface ] [ -m max_ttl] [ -p พอร์ต ]
[ -q nqueries ] [ -s src_addr ] [ -t tos ]
[ w waittime ] [ -z pausemsecs ]
โฮสต์ [ packetlen ]
ลักษณะ
อินเทอร์เน็ตคือการรวมเครือข่ายฮาร์ดแวร์และเครือข่ายที่มีขนาดใหญ่และซับซ้อนเชื่อมต่อกันด้วยเกตเวย์ ติดตามเส้นทางของแพ็กเก็ตตาม (หรือหาเกตเวย์ที่ไม่เหมาะสมซึ่งทิ้งแพ็คเก็ตของคุณ) อาจเป็นเรื่องยาก Traceroute ใช้ โปรโตคอล IP 'เวลาที่จะอยู่' ฟิลด์และความพยายามที่จะลุกขึ้นตอบ ICMP TIME_EXCEEDED จากเกตเวย์แต่ละเส้นทางไปยังโฮสต์บาง
พารามิเตอร์ที่จำเป็นเท่านั้นคือชื่อโฮสต์ปลายทางหรือ หมายเลข IP ค่าดีฟอลต์ของ datagram การสืบสวนคือ 40 ไบต์ แต่อาจเพิ่มขึ้นได้โดยการระบุความยาวของแพ็กเก็ต (เป็นไบต์) หลังจากชื่อโฮสต์ปลายทาง
ตัวเลือกอื่น ๆ ได้แก่
-f
ตั้งเวลาเริ่มต้นในการใช้งานครั้งแรกในแพ็กเก็ต probe ขาออก
-F
ตั้งค่าบิต "ไม่แบ่งส่วน"
-d
เปิดใช้งานดีบักระดับซ็อกเก็ต
-G
ระบุเกตเวย์เส้นทางหลวม (8 สูงสุด)
-ผม
ระบุอินเทอร์เฟซเครือข่ายเพื่อขอรับที่อยู่ IP ต้นทางสำหรับแพ็กเก็ต probe ขาออก นี่เป็นเรื่องปกติที่มีประโยชน์เฉพาะกับโฮสต์แบบ multi-homed เท่านั้น (ดูธง - สำหรับวิธีอื่นในการทำเช่นนี้)
-ผม
ใช้ ICMP ECHO แทน datagrams UDP
-m
ตั้งเวลาสูงสุดที่จะมีชีวิต (จำนวนสูงสุดของ hops) ที่ใช้ในการส่งแพ็กเก็ตออก ค่าดีฟอลต์คือ 30 hops (ค่าดีฟอลต์เดียวกันสำหรับการเชื่อมต่อ TCP)
-n
พิมพ์ที่อยู่ hop แทนตัวเลขและตัวเลข (บันทึกการค้นหาที่อยู่ชื่อของ nameserver สำหรับแต่ละเกตเวย์ที่พบในเส้นทาง)
-p
ตั้งค่าหมายเลขพอร์ต UDP พื้นฐานที่ใช้ในการตรวจสอบ (ค่าเริ่มต้นคือ 33434) Traceroute หวังว่าไม่มีอะไรที่จะฟังในพอร์ต UDP base เพื่อ base + nhops - 1 ที่โฮสต์ปลายทาง (ดังนั้นข้อความ ICMP PORT_UNREACHABLE จะถูกส่งกลับเพื่อยุติเส้นทางการสืบค้นกลับ) หากมีฟังอะไรอยู่ในพอร์ตในช่วงเริ่มต้นตัวเลือกนี้สามารถใช้เพื่อเลือกช่วงพอร์ตที่ไม่ได้ใช้
-r
หลีกเลี่ยงตารางเส้นทางปกติและส่งตรงไปยังโฮสต์ในเครือข่ายที่แนบมา ถ้าโฮสต์ไม่อยู่ในเครือข่ายที่แนบมาโดยตรงข้อผิดพลาดจะถูกส่งกลับ ตัวเลือกนี้สามารถใช้เพื่อ ping โฮสต์ภายในผ่านทางอินเทอร์เฟซที่ไม่มีเส้นทางผ่าน (เช่นหลังจากอินเตอร์เฟซถูกทิ้งโดย ทาง (8C))
-s
ใช้ที่อยู่ IP ต่อไปนี้ (โดยปกติจะเป็นหมายเลข IP ไม่ใช่ชื่อโฮสต์) เป็นที่อยู่ต้นทางในแพ็กเก็ต probe ขาออก ในโฮสต์ multi-homed (ผู้ที่มีที่อยู่ IP มากกว่าหนึ่งแห่ง) ตัวเลือกนี้สามารถใช้เพื่อบังคับให้ที่อยู่ต้นทางเป็นสิ่งอื่นที่ไม่ใช่ที่อยู่ IP ของอินเทอร์เฟซที่มีการส่งแพ็กเก็ต probe ถ้าที่อยู่ IP ไม่ใช่ที่อยู่ติดต่อของเครื่องนี้ข้อผิดพลาดจะถูกส่งกลับและไม่มีการส่งอะไร (ดูธง -i สำหรับวิธีอื่นในการทำเช่นนี้)
t-
ตั้งค่า ชนิดของบริการ ในแพ็กเก็ต probe เป็นค่าต่อไปนี้ (ค่าเริ่มต้นเป็นศูนย์) ค่าต้องเป็นจำนวนเต็มทศนิยมในช่วง 0 ถึง 255 ตัวเลือกนี้สามารถใช้เพื่อดูว่าผลการบริการประเภทต่างๆในเส้นทางต่างๆหรือไม่ (ถ้าคุณไม่ได้รัน 4.4bsd อาจเป็นเรื่องที่ต้องศึกษาเนื่องจากบริการเครือข่ายตามปกติเช่น telnet และ ftp ไม่อนุญาตให้คุณควบคุม TOS) ค่าทั้งหมดของ TOS ไม่ถูกต้องตามกฎหมายหรือมีความหมาย - ดูข้อกำหนด IP สำหรับข้อกำหนด ค่าที่เป็นประโยชน์อาจเป็น ` -t 16 '(ล่าช้าต่ำ) และ` -t 8 ' (throughput สูง)
-v
เอาท์พุท Verbose ได้รับแพคเก็ต ICMP ที่ไม่ใช่ TIME_EXCEEDED และ UNREACHABLEs แล้ว
-w
ตั้งเวลา (เป็นวินาที) เพื่อรอการตอบสนองต่อโพรบ (ค่าเริ่มต้น 5 วินาที)
-x
สลับ checksums ของ IP โดยปกติการทำเช่นนี้จะป้องกัน traceroute จากการคำนวณ checksums ของ ip ในบางกรณีระบบปฏิบัติการสามารถเขียนทับส่วนของแพ็คเก็ตขาออกได้ แต่จะไม่คำนวณ checksum ใหม่ (ดังนั้นในบางกรณีค่าดีฟอลต์คือไม่ได้คำนวณ checksums และใช้ -x ทำให้พวกเขาถูก calcualted) โปรดทราบว่า checksums มักจำเป็นสำหรับการกระโดดครั้งสุดท้ายเมื่อใช้ตัวตรวจวัด ICMP ECHO ( -I ) ดังนั้นจึงมีการคำนวณเมื่อใช้ ICMP เสมอ
-z
กำหนดเวลา (เป็นมิลลิวินาที) เพื่อหยุดชั่วคราวระหว่างการตรวจจับ (ค่าเริ่มต้น 0) ระบบบางระบบเช่น Solaris และเราเตอร์เช่น Ciscos icmp ข้อความอัตรา จำกัด ค่าที่ดีที่จะใช้กับสิ่งนี้คือ 500 (เช่น 1/2 วินาที)
โปรแกรมนี้พยายามติดตามเส้นทางที่แพ็คเก็ต IP จะทำตามโฮสต์อินเทอร์เน็ตบางส่วนโดยการเปิดใช้แพ็คเก็ต UDP probe ที่มีขนาดเล็ก ttl (เวลาที่จะมีชีวิตอยู่) จากนั้นฟังข้อความตอบกลับ "time exceeded" ของ ICMP จากเกตเวย์ เราเริ่มต้นการตรวจสอบของเราด้วย ttl และเพิ่มขึ้นทีละหนึ่งจนกว่าเราจะได้รับ ICMP "port unreachable" (ซึ่งหมายความว่าเราได้รับ "host") หรือกด max (ซึ่งเริ่มต้นที่ 30 hops และสามารถเปลี่ยนแปลงได้ด้วย -m ธง). เครื่องทดสอบสามเครื่อง (เปลี่ยนด้วย -q flag) จะถูกส่งไปที่การตั้งค่า ttl แต่ละเครื่องและพิมพ์บรรทัดที่แสดง ttl, ที่อยู่ของเกตเวย์และเวลาเดินทางรอบของแต่ละโพรบ ถ้าคำตอบของหัววัดมาจากเกตเวย์อื่น ๆ ระบบจะพิมพ์ที่อยู่ของแต่ละระบบตอบกลับ หากไม่มีการตอบสนองภายใน 5 วินาที ช่วงเวลาหมดเวลา (เปลี่ยนด้วยธง -w ) จะมีการพิมพ์ "*" สำหรับการสอบสวนนั้น
เราไม่ต้องการให้โฮสต์ปลายทางประมวลผลแพ็กเก็ต UDP probe ดังนั้นพอร์ตปลายทางถูกตั้งค่าเป็นค่าที่ไม่น่าเป็นไปได้ (ถ้าบางส่วนของปลายทางใช้ค่านั้นสามารถเปลี่ยนได้ด้วยค่า -p )
ตัวอย่างการใช้และผลลัพธ์อาจเป็น:
[yak 71]% traceroute nis.nsf.net traceroute ไปที่ nis.nsf.net (35.1.1.48), 30 hops max, 38 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-c.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 5 ccn -nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140 70.13 (129.140.70.13) 99 ms 99 ms 80 ms 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 11 nic.merit.edu (35.1 .1.48) 239 ms 239 ms 239 msโปรดทราบว่าบรรทัดที่ 2 และ 3 เหมือนกัน สาเหตุนี้เกิดจากเคอร์เนลที่มีปัญหาในระบบ hop ที่ 2 - lbl-csam.arpa - ส่งต่อแพ็คเก็ตด้วย zero ttl (ข้อผิดพลาดในเวอร์ชันแจกแจง 4.3BSD) โปรดทราบว่าคุณต้องคาดเดาเส้นทางที่แพ็คเก็ตกำลังข้ามประเทศเนื่องจาก NSFNet (129.140) ไม่ได้จัดหาคำแปลที่อยู่กับชื่อสำหรับ NSSes
ตัวอย่างที่น่าสนใจคือ:
[yak 72]% traceroute allspice.lcs.mit.edu traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 มิลลิวินาที 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22 .Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 ( 129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 มิลลิวินาที 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26 .0.115) 339 ms 279 ms 279 msโปรดทราบว่าเกตเวย์ 12, 14, 15, 16 และ 17 จะไม่ส่งข้อความ "เกินเวลา" ของ ICMP หรือส่งด้วย ttl ขนาดเล็กเกินไปที่จะเข้าถึงเรา 14 - 17 ใช้รหัส CMS ของ MIT C Gateway ที่ไม่ได้ส่ง "time exceeded" s พระเจ้าเท่านั้นที่รู้ว่าเกิดอะไรขึ้นกับ 12
เกตเวย์เงียบ 12 ในข้างต้นอาจเป็นผลมาจากข้อผิดพลาดในรหัสเครือข่าย 4. [23] BSD (และอนุพันธ์): 4.x (x <= 3) ส่งข้อความที่ไม่สามารถเข้าถึงได้โดยใช้สิ่งที่ ttl ยังคงอยู่ในต้นฉบับ ดาต้า เนื่องจากสำหรับเกตเวย์ที่เหลือ ttl เป็นศูนย์ ICMP "เวลาที่เกิน" จะรับประกันว่าจะไม่ทำให้มันกลับมาให้เรา พฤติกรรมของข้อผิดพลาดนี้ดูน่าสนใจเล็กน้อยเมื่อปรากฏในระบบปลายทาง:
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 มิลลิวินาที 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1 ) 19 ms 39 ms 19 ms 4 ccngw-ner-c.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 นางสาว ! 39 ms! 39 ms!สังเกตว่ามี 12 "เกตเวย์" (13 เป็นปลายทางสุดท้าย) และว่าครึ่งหลังของพวกเขา "หายไป" มีอะไรเกิดขึ้นจริงๆคือการฉีก (Sun-3 ที่รัน Sun OS3.5) กำลังใช้ ttl จากดาต้าแกรมมาถึงเป็น ttl ในการตอบกลับของ ICMP ดังนั้นการตอบกลับจะหมดเวลาในเส้นทางที่ส่งกลับ (โดยไม่ต้องแจ้งให้ผู้อื่นทราบเนื่องจาก ICMP ไม่ได้รับการส่งสำหรับ ICMP) จนกว่าเราจะตรวจสอบกับ ttl ที่มีความยาวอย่างน้อยสองเท่า เช่นฉีกเป็นเพียง 7 hops ไป คำตอบที่ส่งกลับด้วย ttl เท่ากับ 1 เป็นข้ออ้างที่ปัญหานี้มีอยู่ Traceroute พิมพ์ "!" หลังจากเวลาที่ ttl <= 1 เนื่องจากผู้จัดจำหน่ายจัดส่งซอฟต์แวร์ล้าสมัย (DEC's Ultrix, Sun 3.x) หรือซอฟต์แวร์ที่ไม่ได้มาตรฐาน (HPUX) เป็นจำนวนมากคาดว่าปัญหานี้จะเกิดขึ้นบ่อยครั้งและ / หรือดูแลเป้าหมาย โฮสต์ของ probes ของคุณ
คำอธิบายประกอบที่เป็นไปได้อื่น ๆ หลังจากเวลานั้น H !! N หรือ P (host, network or protocol unreachable),! S (เส้นทางต้นทางล้มเหลว),! F- (จำเป็นต้องแยกส่วน - ค่าการค้นพบเส้นทาง MTU ของ RFC1191 จะปรากฏขึ้น) ! X (ห้ามกระทำการสื่อสาร) ,! V (การละเมิดความสำคัญของโฮสต์) ,! C (การตัดทอนความสำคัญก่อน) หรือ ! (รหัสที่ไม่สามารถเข้าถึง ICMP) เหล่านี้ถูกกำหนดโดย RFC1812 (ซึ่งใช้แทนที่ RFC1716) ถ้าเกือบทุกคนส่งผลให้ผลการค้นหาบางประเภทไม่สามารถเข้าถึงได้ผู้ traceroute จะยอมแพ้และออก
โปรแกรมนี้มีวัตถุประสงค์เพื่อใช้ในการทดสอบ, การวัดและการจัดการเครือข่าย ควรใช้เป็นหลักในการแยกความผิดพลาดด้วยตนเอง เนื่องจากโหลดที่สามารถใช้งานบนเครือข่ายได้จึงไม่ควรใช้ traceroute ระหว่างการทำงานปกติหรือจากสคริปต์อัตโนมัติ
ดูสิ่งนี้ด้วย
pathchar (8), netstat (1), ping (8)