ทำไม iperf, scamper และ path MTU discovery packet ที่ได้เห็นด้วยกับ MTU ของ path


11

ลองค้นหาเส้นทาง MTU ระหว่างสอง Debian host ที่คั่นด้วยเราเตอร์ Debian ที่รันกฎ iptables ที่สร้างโดย Shorewall แต่ละโฮสต์ทั้งสองใช้ลิงค์อีเทอร์เน็ตเดี่ยวในขณะที่เราเตอร์ใช้ VLAN ที่ติดแท็กผ่านลิงก์อีเทอร์เน็ตรวมสองตัว

ใช้วิ่งหนี :

root@kitandara:/home/jm# scamper -I "trace -M 10.64.0.2"
traceroute from 10.1.0.5 to 10.64.0.2
 1  10.1.0.1  0.180 ms [mtu: 6128]
 2  10.64.0.2  0.243 ms [mtu: 6128]

ดี: 6128 ไบต์เป็นผลลัพธ์ที่คาดหวัง (อะแดปเตอร์ Realtek อีเธอร์เน็ตราคาถูกไม่สามารถจัดการเฟรมจัมโบ้ในขนาดที่เหมาะสม)

ตอนนี้ให้iperfทำการทดสอบปริมาณงานและบอกเราเกี่ยวกับ MTU โดยวิธี:

root@kitandara:/home/jm# iperf -c 10.64.0.2 -N -m
------------------------------------------------------------
Client connecting to 10.64.0.2, TCP port 5001
TCP window size: 66.2 KByte (default)
------------------------------------------------------------
[  3] local 10.1.0.5 port 59828 connected with 10.64.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1011 MBytes   848 Mbits/sec
[  3] MSS size 6076 bytes (MTU 6116 bytes, unknown interface)

6116 ไบต์? ทำไม

และตอนนี้สำหรับบางสิ่งที่แตกต่างอย่างสิ้นเชิงเรามาดูว่าการรับส่งข้อมูลของเซสชันนี้มีอะไรบ้าง:

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)" | head
Capturing on eth0
  1.308557     10.1.0.5 -> 10.64.0.2    TCP 74 60310 > 5001 [SYN] Seq=0 Win=5340 Len=0 MSS=534 SACK_PERM=1 TSval=101928961 TSecr=0 WS=16
  1.308801    10.64.0.2 -> 10.1.0.5     TCP 74 5001 > 60310 [SYN, ACK] Seq=0 Ack=1 Win=18328 Len=0 MSS=6088 SACK_PERM=1 TSval=3764064056 TSecr=101928961 WS=64

6088 ไบต์ MSS ซึ่งหมายถึง 6128 MTU ... ดี แต่ทำไม iperf ถึงประกาศ 6116 ไบต์ MTU

เมื่อถึงจุดนั้นการเรียกร้องอย่างละเอียดถี่ถ้วนถึงสิ่งที่เกิดขึ้นในระหว่างการติดตามการวิ่งหนี:

root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)"
Capturing on eth0
  0.000000     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33435
  0.000175     10.1.0.1 -> 10.1.0.5     ICMP 86 Time-to-live exceeded (Time to live exceeded in transit)
  0.050358     10.1.0.5 -> 10.64.0.2    UDP 58 Source port: 43870  Destination port: 33436
  0.050592    10.64.0.2 -> 10.1.0.5     ICMP 86 Destination unreachable (Port unreachable)
  0.099790     10.1.0.5 -> 10.64.0.2    UDP 6142 Source port: 43870  Destination port: 33437
  0.100912    10.64.0.2 -> 10.1.0.5     ICMP 590 Destination unreachable (Port unreachable)

แพ็คเก็ตทั้งหมดนั้นมี udp.length 24 ยกเว้นสองอันสุดท้ายที่มี udp.length ของ 6108 ... แต่แล้ว scamper บอกเราได้อย่างไรว่าเส้นทาง MTU คือ 6128?

6108, 6116, 6128 ... MTU ให้เลือกมากมาย!


คำตอบใดช่วยคุณได้บ้าง ถ้าเป็นเช่นนั้นคุณควรยอมรับคำตอบเพื่อที่คำถามจะไม่โผล่ขึ้นมาเรื่อย ๆ โดยมองหาคำตอบ หรือคุณสามารถให้และยอมรับคำตอบของคุณเอง
Ron Maupin

คำตอบ:


4

น่าสนใจมาก.

MSS (ขนาดเซกเมนต์สูงสุด) = MTU - IP header = 6076

6076 + 40 = 6116

เป็นไปได้ไหมว่า Debian กำลังใช้ฟิลด์ตัวเลือก IP ในส่วนหัว IP นั่นอาจเป็น 12 ไบต์พิเศษ ...


เป็นไปได้ไหมที่การจับมือ TCP สร้าง MTU ขนาด 6128 ไบต์จากนั้น iperf พบว่าเขาล้มเหลวในการส่งมากกว่า 6116 ไบต์ในแต่ละครั้งซึ่งจะเป็น MTU เชิงประจักษ์ที่ไม่เกี่ยวข้องกับ "ทางการ" หรือไม่
Jean-Marc Liotier

ไม่ว่าตัวเลือก IP จะมีช่องว่างใดบ้างที่รับประกันความยาว (ตัวเลือก IP + ช่องว่างภายใน) = 32 บิต
Jean-Marc Liotier

12 ไบต์ ... คุณไม่ได้หมายถึง "ตัวเลือก TCP" แทนที่จะเป็น "ตัวเลือก IP" หรือไม่
Jean-Marc Liotier

ฉันสุ่มตัวเลือก TCP ของเซสชัน iperf: เห็นได้ชัดเสมอ 12 ไบต์ (เฉพาะเวลาประทับ)
Jean-Marc Liotier

2
ใน github.com/jasonrm/iperf/blob/ ...... ความคิดเห็นบอกว่า "// ติดตามขนาดการอ่าน -> ให้การบ่งชี้ขนาด MTU" และใน github.com/jasonrm/iperf/blob/ ...... อีกคนรายงานว่า " MSS และ MTU ให้ MSS (หรือคาดเดา) - แปลกเมื่อพิจารณาว่า iperf ควรจะสนับสนุน Path MTU Discovery จริง
Jean-Marc Liotier

3

tshark กำลังรายงานขนาดเฟรมอีเธอร์เน็ต: 6142 - 14 (ส่วนหัวอีเธอร์เน็ต) = 6128 IP bytes

การวิ่งหนีเป็น traceroute ที่มีแพ็คเก็ตขนาดเล็กก่อนที่จะตรวจสอบกับแพ็กเก็ตขนาดใหญ่สำหรับการค้นพบ MTU (นั่นคือเหตุผลที่คุณเห็นแพ็กเก็ตขนาดเล็กตามมาด้วยแพ็คเก็ตขนาดใหญ่) สิ่งนี้มีประโยชน์ในการแยกแยะความแตกต่างระหว่างแพ็กเก็ตทั้งหมดที่ถูกทิ้ง / ไม่ตอบสนองและใหญ่เท่านั้น

https://www.usenix.org/conference/imc-05/inferring-and-debugging-path-mtu-discovery-failures

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.